this post was submitted on 21 Jul 2023
139 points (97.9% liked)

Linux

48715 readers
997 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
139
Coders, what is your workflow on Linux (sh.itjust.works)
submitted 1 year ago by [email protected] to c/[email protected]
135 comments fedilink hide all child comments
 

Hello,

I installed Ubuntu a few months ago on my work laptop and I've been running and loving it since.

However, I am used to VsCode, so this is what I am using in Ubuntu as well.

So I am curious, what kind of coding so you do? And what is your workflow.

I am an embedded firware developper and mainly use C. I am cross compiling my code in VsCode for a FPGA from Xilinx (dual core arm + PL)

Never dove into make files and cmake more than what I needed in the past, but I had an opportunity to learn CMake and build a project from it.

So my workflow is :

  1. Code in VsCode
  2. Build in CMake
  3. Transfer the app through scp on the target with a custom script (target is running petalinux, which is yocto + Xilinx recipes)
  4. Use gdb server to debug the code.

It's a pretty simple workflow, but I'd like to know what you guys are running so that I can maybe upgrade my workflow.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 5 points 1 year ago* (last edited 1 year ago) (1 children)

I vehemently dislike coding directly on my workstation and do all of my development in remote VMs via SSH, when possible. My work MBP is a glorified SSH terminal with a web browser. I got my start in the industry with remote SysAdmin stuff so, it feels pretty natural.

For an IDE, I use Neovim, currently with a plugin distribution - Neovim because I got used to the vim syntax as a SysAdmin and the distribution because I can't justify sinking more time into tuning my env for a bit but am intending to scrap it all around the holidays or so.

Most of my work is in Go or Python. At home, it's a mix of CircuitPython, C, and I'm picking up some Rust (mainly embedded for C and Rust). Will be starting to learn Verilog this weekend.

For Go and Python, I tend to lean towards a TDD approach, even if it gets a bit derided by coding streamers.

My workflow tends to be:

  1. Prototype desired functionality to get at least individual parts working.
  2. Start from scratch and rough out any classes/structs and test suite boilerplate.
  3. Start the red->green->refactor loop, giving extra granularity to parts of code that I am less confident in.
  4. Once all intended functionality is implemented, run manual tests (I generally develop tools).
  5. Fix bugs that unit tests failed to prevent or I failed to anticipate.
  6. Repeat 4 and 5 until acceptable.
  7. Prepare commit.
  8. Push commit and receive failure because I haven't fully configured my formatters to clean trailing whitespace and VT100-compatible line lengths.
  9. Push commit again and send for code review.

Currently, my build automation is kinda in CMake. Really, the Makefile is just calling a build in a docker container.

For C, Rust, and Verilog, I'm not yet familiar enough to have yet established workflows.

ETA: I think I just got the same FPGA as you! Xilinx Zync-7020 (Digilent Arty Z7-20).

[–] [email protected] 2 points 1 year ago (1 children)

Almost the same FPGA, we use the Mars ZX2 from Enclustra which uses the zynq7010.

The TDD approach is a hard sell to companies because it's hard to quantify what time is saved in the end and the MBAs of this world have a hard time with that.

[–] [email protected] 2 points 1 year ago

I think that some companies and devs also have a bad taste in their mouth due to overzealous adopters and policies, along with using mocks that are not necessarily going to maintain parity with their production counterparts. Some things are a bit silly to test and mocks like that are going to introduce future technical debt.