Snild

> definitely cannot afford to get on Spotify

How so? There aren't necessarily any upfront costs for getting on Spotify; several aggregators offer a "we take a cut of your earnings" model.

One could ask the same thing about `for` and `while`: why not just use `if`s and `goto`s?

Because they're convenient and useful constructs. I don't know if `breakelse` is too, but maybe -- especially when part of a `?` operation.

> "must be able to lift 50 lbs"

Is that a real thing?

I've had emails about a blindness awareness event where the text was all in a screenshot of text. I don't know the state of the art of screen readers, but I have to assume that text is at least _better_. :)

AFAIK, there are no rules limiting what tags you may use -- you can make up your own if you like. And people have. Here's what the kernel git says right now:

    linux$ git log | sed -nE 's/^ *([^ ]+-by:).*$/\1/p' | tr '[:upper:]' '[:lower:]' | sort | uniq -c | egrep -v ' [0-9] '
         20 ack-by:
         74 acked-and-tested-by:
     195801 acked-by:
         24 acked-for-backlight-by:
         49 acked-for-mfd-by:
         19 acked-in-principle-or-something-like-that-by:
         21 acked-off-by:
         10 analysed-by:
         47 analyzed-by:
         26 based-on-a-patch-by:
         97 based-on-patch-by:
         15 based-on-work-by:
        128 bisected-by:
         18 boot-tested-by:
         37 build-tested-by:
        147 co-authored-by:
       4779 co-developed-by:
        175 debugged-by:
         60 diagnosed-by:
         11 disliked-by:
         11 eviewed-by:
         51 fixed-by:
         18 fix-suggested-by:
         32 found-by:
         48 generated-by:
         19 improvements-by:
         79 inspired-by:
         18 located-by:
         10 not-acked-by:
         86 noticed-by:
         30 original-by:
        140 originally-by:
         95 original-patch-by:
         44 pointed-out-by:
         14 proposed-by:
         10 reivewed-by:
         22 reported-and-acked-by:
         12 reported-and-analyzed-by:
         77 reported-and-bisected-by:
         12 reported-and-debugged-by:
         23 reported-and-suggested-by:
       3017 reported-and-tested-by:
         21 reported-bisected-and-tested-by:
      58990 reported-by:
         11 requested-and-tested-by:
        363 requested-by:
         10 review-by:
         55 reviewd-by:
        513 reviewed-and-tested-by:
     304543 reviewed-by:
         16 reviewed-off-by:
         67 reviwed-by:
         11 root-caused-by:
         29 sigend-off-by:
         10 signed-by:
        157 signed-of-by:
    2253448 signed-off-by:
         59 singed-off-by:
         54 spotted-by:
         32 suggested-and-acked-by:
         12 suggested-and-reviewed-by:
         17 suggested-and-tested-by:
      15568 suggested-by:
         48 tested-and-acked-by:
         22 tested-and-reported-by:
         35 tested-and-reviewed-by:
      62630 tested-by:
         12 verified-by:

My suggestions are both there (far less often than "Reported-by:", but that's not surprising). I think "Analyzed-by:", "Debugged-by", "Diagnosed-by", "Originally-by:", or "Original-patch-by:" would also have worked.

If you don't filter out the tags with less than 10 uses, there are some fun ones. For example, "You're-my-ding-a-ling-by:" should be used more often. :)

> There's no such thing as a "have-debugged-and-contributed-actual-code-to-fix-it:" tag.

"Based-on-patch-by:" and/or "Root-caused-by:" comes pretty close, I think.

It may seem like a small difference, but I understand the author's disappointment.

> you’re like the person at the all-you-can-eat buffet who goes back for a third helping. They make the most money from indifferent, lukewarm fans

I don't think this is correct. Spotify doesn't pay a fixed rate per stream. Instead, they reserve some part of revenue for artist compensation, and then divide that based on the amount of streams and artist- or label-specific deals.

Straight from the horse's mouth: https://support.spotify.com/us/artists/article/royalties/

> We distribute the net revenue from Premium subscription fees and ads to rightsholders. To calculate net revenue, we subtract the money we collect but don’t get to keep. This includes payments for things like taxes, credit card processing fees, and billing, along with some other things like sales commissions. From there, the rightsholder’s share of net revenue is determined by streamshare.

> We calculate streamshare by tallying the total number of streams in a given month and determining what proportion of those streams were people listening to music owned or controlled by a particular rightsholder.

> Contrary to what you might have heard, Spotify does not pay artist royalties according to a per-play or per-stream rate; the royalty payments that artists receive might vary according to differences in how their music is streamed or the agreements they have with labels or distributors.

Though I guess that means that lukewarm users with few streams cause higher per-stream rates, which might be indirectly beneficial to Spotify.

That's not to say that the system is completely fair. Presumably, bigger artists and labels get preferential treatment in share calculations. Also, if I listen to only Ben Prunty's FTL soundtrack for a month, he doesn't get all the net revenue from my subscription; those streams are diluted in the global stream counts.

But I can't hang my laptop from a USB cable. :)

Physical machine, in a server room at Sony's Lund office. Custom order of several machines from Compliq, a small local shop.

It's a Threadripper-something, 128GB RAM, and nvme disks totaling 9-10 TB (plus a sata SSD for the OS, and maybe a big HDD for the mirror). I use btrfs' raid to join the repo disks, while others use other solutions (e.g. ext4 on top of mdraid). I also run btrfs compression, which saves a lot of space for very little cost (iirc, something like 1% extra time for a full Android build, but ymmv).

Most of us share the build machine with 1-3 other engineers, which is fine because we rarely need to make (big) builds at the same time. Android is not small, and having multiple copies of the complete history for multiple people would be impractical, so we have a custom git/repo mirroring solution that keeps our various checkouts from growing out of hand.

People use whatever tool they like to connect to the machine. I've seen remote desktop of some sort, xpra, mosh... Personally, I'm using ssh and screen, with some ssh_config aliases for quick access to specific product branches.

When it's time to flash a build to a device, rsync is great. I believe AOSP aims for hermetic/reproducible builds, which enables big speedups from rsync.

> The next best thing is to use the laptop docked but closed

That's what I do, combined with a 64-thread/128GB build machine.

In fact, I'm so happy with my discontinued HP UltraSlim docks mounted vertically on the side of my desk/divider that I went to IT and special-ordered the last model that fit those docks. My new laptop is five years old. Worth it! :)

I looked it up, and you are technically correct ("the best kind of correct").

https://lagen.nu/1960:729#P19S1

> 19 § När ett exemplar av ett verk med upphovsmannens samtycke har överlåtits inom Europeiska ekonomiska samarbetsområdet, får exemplaret spridas vidare.

Translated:

> 19 § When a specimen, with the consent of the author, has been transferred within the European economic area, the specimen may be further transferred.

The law goes on to carve out exceptions for computer programs and movies specifically, as well as renting generally -- those kinds of transfers are not allowed without author approval.

However, in combination with Biblioteksersättningen/författarfonden ("the library compensation/author fund"), which collects money based on the amount of lending in public libraries and distributes it to authors, it comes pretty close to statutory licensing in practice. It's not immediately clear to me that the payout is proportionally divided, though, so depending on how that skews, I may be way off.

Compulsory/statutory licensing would be one solution. As I understand it, that's what allows libraries to exist. Music on the radio (at least here in Sweden) is handled through collective licensing, which is nominally optional, but practically impossible to avoid if you want any radio money.

The incentive of exclusivity could be reasonably preserved by making the statutory license valid only after some amount of time has passed since release.

Isn't that the whole point of jobs -- making a living?

Your assertion makes no sense to me. I feel like I'm missing something.

Machines are not people, and don't enjoy the same rights as us.

(And I would not call it "learning", at least not in the same meaning of the word as for humans, but that's a more philosophical discussion.)

People having fun? Not on my watch!

Each year does vary slightly in theme and focus, so it's possible you'll have more fun this time if you give it another chance. Or not. But remember that it's never too late to give up. :)

My favorite so far is 2019, where several of the problems had you write and extend an emulator for the imaginary (and wacky) "IntCode" computer.

> I assumed there is a limit on the amount of buffered and not yet committed data, and when that is cross the call would block until more data is flushed to disk.

There is. It's tunable through /proc/sys/vm/dirty_ratio. When there is that much write cache, application writes will start to writeback synchronously.

There is also dirty_background_ratio, which is the threshold at which writeback starts happening in the background (that is, in a kernel thread).

Not with liberal use of `unsafe` it can't.

Benefiting from the large provider's reputation in regards to spam blocklists etc.

It is definitely a hard switch to make when you're used to being able to just _write_ what you want, rather than having to go look for the block and drag it into place. :)

> If the goal is to ultimately learn programming with industry standard tools

It has variables, if, else, different kinds of loops, event handlers... Of course it still isn't "real" programming, but it does teach some basic concepts of it, while still being relatively easy for a child to use.

Every variable has a checkbox they makes it show on screen: https://en.scratch-wiki.info/wiki/File:Checkbox_to_show_or_h...

There is also a command block to show or hide it dynamically.

I guess it's a bit of a philosophical disagreement.

In my view: I don't believe a machine (at least not any we're capable of creating) can truly learn.

Copilot is a machine working on its inputs. Humans think and create. Maybe it can be argued that humans are just more complicated machines, but I don't think most people would agree with such an equivalency.

Copilot is constructed almost entirely from others' code. There's a tiny fraction of original "ai glue" in there, but the end product is arguably a derivative work of all that code it was trained on. As is its output.

It can also be argued that the AI part is really just an obfuscating copy machine. One that was created specifically for that task.

And of course, the real killing blow: if/when it reproduces training code verbatim, and you don't notice... will "copilot did it" be a valid defense in court? There are different opinions on that I guess, but no one knows for sure -- and I wouldn't take that risk.

My library is long gone, but let's do some math instead.

A CD can hold 700 MB of data. 1 TB will hold 1428 full CD images. Of course, not all albums fill the whole CD, so it'll be even more once the audio is extracted to uncompressed audio files. That's already way more albums than I listen to on Spotify.

Then add some compression: my rule of thumb is 10x for mp3 and 2x for flac, but that may be a bit optimistic. Even assuming a low compression ratio of 1.5x, that leaves us with more than 2100 full albums.

I don't think I will ever listen to that much different music.

And Spotify doesn't even have the good version of my favorite Robyn album, and Kyle Gass Band only just reappeared after missing for months. Maybe I should start a collection, too.

So many good ones, I can't choose.

Black Jeopardy with Tom Hanks -- https://www.youtube.com/watch?v=O7VaXlMvAvk

Close Encounter -- https://www.youtube.com/watch?v=PfPdYYsEfAE

Disney Housewives -- https://www.youtube.com/watch?v=b-2fnZfK9Lg

Friendos -- https://www.youtube.com/watch?v=7oPe80mdcZg

GE Big Boys -- https://www.youtube.com/watch?v=vZRzJJcq6Rs

Miley Cyrus and Kyle Mooney's Sex Tape -- https://www.youtube.com/watch?v=KEqStuivoio

Santa Baby -- https://www.youtube.com/watch?v=CkrpvCs-kfE

The Day Beyoncé Turned Black -- https://www.youtube.com/watch?v=ociMBfkDG1w

Wells for Boys -- https://www.youtube.com/watch?v=BONhk-hbiXk

World War II 101 -- https://www.youtube.com/watch?v=Bdf_XdDwc-o

What if I don't like my initials?

I share them with a political party that I disagree with, and it always irks when I am called by them.

Maybe I should create an account and check if there's a setting before I whine about it... but this is still the internet!

I don't think I had any specific reason for picking OpenSUSE, at least none that I can remember. Their Tumbleweed rolling release seemed interesting to me.

As for the experience, I mostly like it. There is some re-learning to do (zypper not apt!), but the vast majority of things are the same. Since the distro isn't as popular, there are fewer asked-and-answered questions out there, but most Ubuntu answers work with minimal adaptation and the OpenSUSE wiki is pretty good.

Another downside of going non-Debian is that proprietary software may be less well-supported. I think I only have Steam and Spotify, and they have worked well so far.

Same here: Ubuntu was my first distro, and I've been using variants of it since 2006. This winter, I switched to OpenSUSE, with Ubuntu's insistence on pushing snap on me being the biggest reason.

I am using mbsync with Evolution, and it has worked well for me. Might be worth noting that I'm only syncing in one direction though.

You are technically correct; the best kind of correct. Writing as if they were changes is a little sloppy, though convenient.

> E.g., rebasing. I don’t completely understand what it is supposed to achieve.

I recognize that this is just one example of probably many things you dislike about git, and I will not be able to change your mind about it, but:

Rebasing is essentially the user saying "actually, I wanted to make these changes on top of this different base". This is useful if you perhaps started some work on the wrong branch, or just want to test your change on top of the most recent upstream code.

> Nothing makes sense.

I think there are two key realizations to understanding git:

1. It's a directed acyclic graph. That's a very nice data structure to think and reason about.

2. Everyone can have their own version of this graph, so committing a change and sharing it with others are two different operations (and fetching others' changes is yet another).

With those things in mind:

* git rebase copies an arm of the graph and grafts it onto a different starting node

* git cherry-pick copies an arbitrary node in the graph

* git push shares your local additions to the graph with others (usually through a server)

* git fetch updates your local graph (usually from a server)

* git merge joins two arms of the graph, so that one can enjoy the changes from both at the same time