xorcist

If I am applying for a job, I invest my (valuable) time in them. I expect my counterpart to return that favour.

Anything else would be a quick bail for me, and I expect over time anyone who hires in disrespectful ways will get the candidates they deserve.

There's no end how complicated you can make things for yourself, if you really want to.

What you should do is make software good enough so your users will use it, and publish the source code under a free license. The first Debian developer that uses and likes your software will package it, and the virtous cycle can start. It can be tempting to "own" the user experience (after all, everone wants to own their customer) but one has to let go of that thought. Updates can not be expected to get pushed out the same day when you don't own the customer, but that's overall a good thing.

Ask the distro people what you can do to make their work easier, listen to them, but do not try to do their work for them. Unless you live in that distro you are unlikely to understand how they expect your software to behave and the nuances of how it should be packaged.

One of the good ideas about Linux packaging is that it is not the same people that make the software that package it. Code can be reviewed. Bad ideas can be caught. This principle is sometimes violated, but that violations happen doesn't make them a good idea. We live in a world where no one should execute random software from the Internet without any form of reputation or review, and distribution packaging suggests one way we can accomplish that. A way that has survived three decades, after all, so maybe it's worth listening to.

Giving software the rights to overwrite itself is not good design.

Mozilla can, because they are so large they can have people spend their days working on it. No one else should.

TIL that the Worms soundtrack was by Dr. Awesome / Crusaders. Still loving it!

> Your ISP proactively shares your web history with the state

I have no idea what you are referring to here but that is most certainly not the case in most democratic countries. Where common carrier or telecom immunity is a thing they do not want to know more than they are legally obliged to know.

Neither phones, nor email, not even usenet had this impact. Social media did.

The problem is not with the technology but those that control it. (Some would probably say, the fact that any one actor controls it in the first place.)

Our only means of communication in modern society are a few advertising platforms in hands of even fewer owners, and the engineers hired to run it are busy engagementmaxxing.

> years and years of shows where you are 100% certain characters will be unharmed

Unless your culture sphere consists solely of children's books and Disney movies, that is just a bizarre thing to say. Heroic deaths and tragedys has been a staple of storytelling since the dawn of time. Greeks even had a word for it. Any random book (for adults) during the past several centuries is likely to include the subject, with a hundful exceptions of course. But a classic way to build tension in storytellin is with a tragedy.

Are we all pretending we have no empirical data on this? How many RCEs has there been in popular web browsers over the past two decades (dozens? hundreds?), compared to how many RCEs there has been in the OpenSSH client (perhaps we can make it one if we include xterm in that)?

That is also an unfortunate design on Matrix' part. I had no problem migrating data when changing from ejabberd to Prosody. Because they are open source, so it's not really a problem to export to ad-hoc text and import again.

But Matrix closely follows proprietary products in its design, and the database is treated like some internal affair that you are not to meddle in. You'd have to reverse engineer the data format from source code, which is not practical for hobbyists.

I believe you are supposed to use an LLM on the receiving side to compress them again.

This is supposed to help our economic growth during the coming decade.

Right. LLMs are text production machines.

You can also view them as data expansion tools. They expand an input to an arbitrary long text. That text contains roughly the same amount of information as was contained in the input to begin with.

This is not very useful unless your work is content production. More useful is when the output length is shorter than the input. Then it is a (lossy) data compression tool. These are, as we all know, very useful for images and sound but now we have them for text too.

Network switches typically aren't known for their outstanding security record, but the vlan tags themselves are trivial and should be hard to mess up. Should someone hack your switch all bets are off, but as long as you don't have management accessible in-band you should be fine. Security problems are more likely to stem from bad configuration.

> Can't a device on VLAN1 not peek at VLAN2 traffic if it sits on physical connection where packets from both VLANs happen to travel?

That would be an exceptionally weird configuration. If a device "sits on VLAN1" that typically means that it's on an "untagged" port where only VLAN1 traffic is allowed. Ports that carry multiple VLANs are "tagged" ports and you normally wouldn't say they "sit" on any specific VLAN, precisely because that port carries tagged traffic for multiple VLANs. It's at best an irregular use of the terminology but likely a misunderstanding somewhere.

There's also always the flip side: When the police shows up because of your illegal acitivities, you have a rogue proxy server running. All bought in good faith of course.

Not legal advice.

(It would surprise me greatly if we as a society let these gadgets be sold openly from here on.)

Exactly! You would have a number of oil states competing, and that's it.

They have everything to win. It's opposite of the PGA/LIV situation, the breakout group have the stronger trademark and the better teams. It's baffling that UEFA didn't move in already when FIFA was too greedy even for EA, which is saying something.

Why only now? UEFA should boycott the world cup, period. It should have been enough even before the Balogun nonsense. They have the best league and the best teams, they have the know how and could easily host the UEFA World Cup.

They could host a tournament without the pay-to-win arbitrary overruling of red cards and the clownish half time entertainment. Nobody would care about the FIFA World Cup.

Fork it!

Just imagine, had this been a Facebook event instead, none of this information would have been available to us outsiders. The open web lives, even if bruised and limping.

Fretless bass is quite popular though, and they play chords all the time. What would 80s music have been without them?

And all uprights are fretless, too. And cellos of course. They can also play chords.

Due to the widespread idea that climate prediction has been predicting doom and gloom all the time, and has always been wrong about it, I have been entertaining myself by revisiting old climate predictions from 20 years ago. I can highly recommend it.

I mean, predicting the climate must be one of the hardest numerical simulations you can run. Climate models are famously incomplete. But the results turned out to be way more accurate than I would have thought. That's some impressive modeling, and I would assume that models have only improved since then.

The most chilling thing (and not in a good way) about it is that popular science type repotrs for the general public usually indicate an interval between a good case and a bad case, with a nice line in between. In retrospect we have been pretty much perfectly tracking the bad case line ever since.

In this specific case, echo can't fail to there's no need for any of that:

  [ -z "$1" ] && echo "fail" >&2 && exit 1

People are different, and I think we have to respect that. In my role I tend to have to fix problems in other people's code probably on a weekly basis. Commits that do too much, or too little, or are generally hard to understand are the number one reason this takes time. Crafting readable commits takes seconds out of your work day. Please be considerate to all your future colleagues.

You only have to learn three things to use a computer: Your shell, your editor, and your version control system.

That's it. That basic knowledge will carry you far, and will be useful a decade from now. Those are the three best afternoons you can spend. Do it out of respect for the computer.

This is a perfect use for tags. They allocate no extra storage space, and act as "savepoints" which you can refer to at any time. (Branches move, tags stay put.) They also guarantee that those loose ends are not garbage collected. Sometimes I delete a bunch of old ones, but any codebase of mine will at any time have a handful of old and probably useless tags. But that's ok.

Thank you for proving my point by fixating on the raw sewage part.

Contrary to what you think, no plumber would abstain from fixing plumbing permanently, even if it meant no more wading through said sewage.

That thought experiment says more about your thoughts on plumbers than anything else.

As soon as installation of software outside Play Store is made impossible, any such discussion is moot already anyway.

While probably true, I'm not sure how much Fedora can be owned really. We should give credit where credit is due though: IBM has, together with Intel, Red Hat, and a few others, been very supportive of the Linux ecosystem since early on. Their scalability work, their GPLing of code, and upstreaming of said code, did a lot for people to look at Linux seriously. There are obviously people inside IBM who understand this stuff. So there should be hope.

How does that work? Does one agent write the tests from spec, and then another agent is told "make tests pass", or do you write the tests manually?

It does sound like a possible way to parallelize agentic work, but I'd be surprised if the results are better than a non-TDD approach where the agent would write both tests and code from spec.

I would expect the agent to suffer the same problems humans do with TDD, namely that it is hard or impossible to properly model data ("understand the problem") from tests alone. And if we are to believe Frederick Brooks, as I think we should, a good data model is imperative to good code. That is why TDD failed in the real world, and that problem is excarbated with agentic coding.

It is time we as an engineering discipline sober up about which methodologies work in the real world after decades of empirical data. Name the ten most successful software projects right in front of you now, and I bet that exactly none of them were designed from tests. One would expect at least one, from decades of best selling books on the subject.

In fact, it is high time to put the OOP paradigm under scrutiny and see which promises were delivered on and which weren't. Apart from a few functional languages, mainstream language design got stale for a long time until we finally got Rust and Go which broke with the strict paradigm.

How could it possibly be interpreted literally?

Instating a monarchy with cash as regent? How would that work in daily life?

I call this software "products", and not in a good sense.

A product isn't necessarily designed by someone who cares about, or even understands, the problem at hand.

Or ever. If we want to some colleague to tell us what is good code and what isn't, can we please pick someone who at least once demonstratably delivered good software? Bonus points if it was a group effort, and if it was on time.

Common for all these "industry leaders" is that they all write books and give speeches. I'd rather listen to someone who designed successful software such as git or OpenSSH than someone who designed a salary system in the 90s which, it turns out, was scrapped two years later for being a mess. Giving yourself a stage name is not a merit in itself.

There is something to be said for actually understanding the problem first. Did we learn nothing from the TDD nonsense in the 00s?

The famous InfoQ sudoku software design example was chronicled on HN here and should be required reading for anyone who cares about clean code in practice:

https://news.ycombinator.com/item?id=3033446