DEV Community: Daniel Uber

Apt source extracts to local directory

Daniel Uber — Mon, 06 Dec 2021 18:13:53 +0000

I wanted today to check what the installed wc program was actually doing (a peer mentioned a bizarre behavior in the reported number of lines in the file, reported by wc -l). The manual specified this is a count of the newline characters in the file.

Sometimes, when people say "newlines" or "lines" they mean slightly different things, so I wanted to verify this was in fact only counting the occurrences of the byte 0x0a ('\n').

So I downloaded the source. I use debian, and remembered you could call apt-get source $package or apt source $package to get both the upstream (original) version and any vendor provided patches. I helpfully knew that wc is from a GNU package named coreutils so I ran what seemed like a reasonable command (it worked the first time):

sudo apt source coreutils

This spit out a bit of information - the last warning was confusing to me, the earlier parts are expected - fetch the package description (pgp signed message from Michael Stone, a debian maintainer that includes the package list, dependencies, and checksums for the files), the original upstream package from GNU, the pgp signature for the original upstream, and the applied patches from the debian maintainers not present in the upstream package (diff)

Reading package lists... Done
Need to get 5,584 kB of source archives.
Get:1 http://deb.debian.org/debian bullseye/main coreutils 8.32-4 (dsc) [2,096 B]
Get:2 http://deb.debian.org/debian bullseye/main coreutils 8.32-4 (tar) [5,548 kB]
Get:3 http://deb.debian.org/debian bullseye/main coreutils 8.32-4 (asc) [833 B]
Get:4 http://deb.debian.org/debian bullseye/main coreutils 8.32-4 (diff) [33.0 kB]
Fetched 5,584 kB in 2s (2,910 kB/s)  
dpkg-source: info: extracting coreutils in coreutils-8.32
dpkg-source: info: unpacking coreutils_8.32.orig.tar.xz
dpkg-source: info: unpacking coreutils_8.32-4.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 61_whoips.patch
dpkg-source: info: applying 63_dd-appenderrors.patch
dpkg-source: info: applying 72_id_checkngroups.patch
dpkg-source: info: applying 85_timer_settime.patch
dpkg-source: info: applying 99_kfbsd_fstat_patch.patch
dpkg-source: info: applying restore-ls-behavior-8.31.patch
W: Download is performed unsandboxed as root as file 'coreutils_8.32-4.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

I didn't understand why the sandbox warning showed up - and I didn't know where the files went. I assumed /usr/src/ was a good place for system sources, and saw nothing there (this would also be the place the kernel sources are expected, and in a bsd system most of the sources for installed packages might have gone here).

I didn't see much help in the man page for apt source (which is medium hard to search for because an unrelated meaning of source is "which servers or disks should apt check for packages when installing").

Ultimately, the sandbox warning was explained when I found these four files had been downloaded in the current working directory (my home in this case) and that the intent was to set the files to my user's permissions. Calling apt with sudo in this case didn't help (the commands ran as root, and couldn't sandbox root owned files).

What I learned:

call apt source in a directory you want the source tree to reside.
don't call apt source as root if you want to access the sources as a user.

Oh, and the initial question, about wc? It's comparing directly for the \n character - as documented and shown in the source. Also, wc is way more complicated than I imagined it would be (because of multibyte characters in one case, and optimization to use cpu vector extensions when present in another), but the main logic looks like it only increments the lines counter when it encounters a newline character (what I set out to confirm):

                case '\n':
                  lines++;

I'm Joining the Forem Team

Daniel Uber — Tue, 09 Mar 2021 21:48:02 +0000

It's my first day at Forem, the company that operates DEV. I'm excited to be here, part of this really amazing team. In the genre-defying nature of modern work, I've taken up a QA role as a software engineer. This means part-time automation developer, part-time shift-left advocate, part-time developer experience triage, part-time support triage, part-time test refactoring and maintenance, and full-time debugger. If this works out well, it will be a lot more like SRE the way Google described it in their book.

Software engineers tasked with automation and response to issues, rather than adding operations/systems engineers to manage these resources and handle incidents (or do manual end-to-end testing for QA).

Like a lot of Ruby projects, Forem internally already has a strong culture of testing and test coverage, as well as actively monitoring and paying down tech debt. A lot of the green field setup work one might expect as the first QA hire should already be out of the way. This means I can start on hard and interesting problems. Who doesn't like solving hard problems?

I'm a generalist, rather than an expert or specialist in any one subject. I hope I can make things generally smoother, faster, and more reliable at Forem.

You may ask yourself, "Well, how did I get here?"

I like to say I had a non-linear career path, and I sure feel like I slipped in the back door to become a developer. While I had a fairly traditional math and computer science education in college, the "requirements" for most entry-level programming jobs were a strong pain point when trying to find a good fit after school.

I ended up as a webhosting server admin for a number of years, worked as a SaaS support engineer for a few years after that. Eventually, I built up enough immediate experience and general expertise with that system that I was the go-to rubber duck in the office when someone was working in a part of the system they were unfamiliar with. Whether I'd written or designed any of the code was irrelevant as long as I'd read it carefully and recently enough to know what it did, what role it played in the system, what called into it, what supported it, and where the output went and why.

The fact that during this growth I changed my job title to "Software Engineer" was accidental, and I think I'm a loose fit for that job title the way many companies describe it. However, I did gain a lot of experience watching the Rails culture at work as well as the friction or centrifugal forces present in trying to knit together a larger and larger team as we grew. I also discovered the value of intentional, regular, software maintenance.

You may ask yourself, "Am I right, am I wrong?"

Forem is an exciting breath of fresh air for me since the project and its plans are so directly connected to the desires and needs of the users. I think this level of connectedness to the community we're serving and openness to improvement is going to be a huge boost in the value I get from the work I do. I hope this provides something of real value to a lot of people, and I hope I can see that value when it's delivered.

Under the rocks and stones, there is water underground

When I'm not working, I enjoy walking and biking. Now that it's spring in Chicago I expect to get more time on my bike than I did this winter. I read a lot, kind of non-selectively, in English and French, and I've started reading in Italian recently to keep my mind comfortable being confused. Learning how to guess well, make decisions when you're sure you don't have all the information, and recognizing things you've seen before are powerful skills in gaining technical competence. A lot of those just happen to overlap with diving headfirst into foreign language acquisition.

When I'm fooling around with computers outside of work, I use emacs, lisp, and enjoy mathematical computation. Even though I'm probably not especially skilled at any of them, they're different enough from web development to keep me uncomfortable and interested. These are the programs where I can't just "pound out code" and have it work right the first time which helps reinforce my humility and willingness to approach new things.

Same as it ever was, same as it ever was

So like many of us have experienced several times in our lives, it's my first day at a new job. So far, so good. I'm both excited and scared to see what the immediate future holds. I've got a lot of reserve optimism stored up about how great this is going to be for me as a growth opportunity, for Forem as a growing platform and product laying a strong foundation, and for the community to add one more voice.

I'm eager to find out how we at Forem interact and integrate the company with the product and the product with the community. I expect to have more ideas than I can possibly deliver, more opinions than I will win arguments for, and more asked of me than anyone has ever asked of me before.