GuB-42

I don't decide, doing anything involve some risks, some of them can't be eliminated. Or, I guess I can decide to not do anything, but it won't get me anywhere.

To go back with the human analogy. I have a server in a datacenter, there is a weakness in that someone can go to the machine physically and do nasty stuff, including hitting it with a literal hammer. This is a risk, but I can't do anything about it. Someone has to do the maintenance. But it can be mitigated with access control to the datacenter, among other things.

If the door to the server room can be opened with a toothpick, that's a vulnerability and it has to be fixed, because to "real" solution of not letting anyone in is not viable. I didn't chose to let people in the server room, it is just impossible not to.

Progress is in doing more work with less impact. Burning fossils more efficiently and burning less of them because we have an alternative are both progress.

> Built really cool Photo, Video, Music editing/CAD software and released it for free

Built, really? From what I have seen, it is more like knockoffs, strictly worse than the original except that they are free, and unlike cracks, presumably legal.

I agree with the other two, though it is getting close to the cracking scene, which is certainly cool, but a bit different in sprit to what led to Linux and Wikipedia.

What we are seeing more of is "I had this specific need and I quickly vibecoded some software to do it". This is actually really cool, but it doesn't scale. These tools answer to the need of one person, they may break everywhere else but who cares, it does the job. But for a community project, it is not acceptable, everything has to work for everyone.

We would have inefficient and polluting engines, leaded gasoline, steam engines burning coal, no high performance plastics, and probably more even wars around oil and gas and slower economy leading to less resource to fund battery research...

I mean, batteries and solar panels are cool, but thinking about the future doesn't mean we should forget the present. The advance we could have gotten by diverting funding away from fossil fuels and towards renewables and batteries is to balance with the damage caused by using outdated fossil fuel technology before the transition.

Cities are breathable now thanks to all the progresses modern engines have made. They will be even more breathable with zero emission cars, but I prefer to wait a bit more in these conditions than waiting a bit less in a smog filled city.

These labs had one thing in common: they were funded by monopolies. Xerox with copy machines, Bell with the telephone, General Electric is also known for its monopolistic practices.

And you probably heard about these little things called LLMs, that's Google research, yup, another quasi-monopoly. And it wasn't product centric, in fact, Google turned out to be pretty bad at making a product out of their research, that's how OpenAI took over.

Monopolies are bad for consumers, but there is also some good. Because they make tons of money and don't have to worry about competitors, they can invest a lot into fundamental research with a long term perspective. A competitive industry rewards shorter term strategy, because companies can't afford to wait 20 years for the next big thing if their competitor takes over after 2 years with the next small thing.

But moving faster and without accountability is generally worse.

In a perfect world, we would move at a steady pace, as to keep up with the world but without rushing, and people would be accountable without a heavy bureaucratic processes.

Unfortunately, that's not how it works in practice, at least not for long, so between the two, we usually favor the slow and bureaucratic process when safety and reliability matter.

Security works by layers.

The physics makes the rowhammer impossible to fix in practice, but you can add various mitigations: scrambling, ECC, detection and response, etc... On the application level, you can also make it so that it is not possible to do a rowhammer in the first place. Fix everything that can be fixed and mitigate what can't be fixed.

And there is another security issue that can't be fixed, and is much worse than rowhammer: people. But we can't remove people, just like we can't remove DRAM for the performance level we need, so we mitigate the risk. It is not game over because we have other layers of security.

You can't decide to stop being black, but you can choose to not buy an iPhone. That's why race is a protected category and your smartphone is not.

And it is not "braindead". EncroChat was a "privacy service", selling phones featuring E2E encryption, disabled cameras and microphones, etc... Even though it wasn't marketed as such, it was mostly a service for criminals. And they effectively searched everyone using these devices (they hacked the firmware), and maybe a few people who weren't criminals got searched, as it happens in many investigations, most people turned out to be. The result was many arrests of people you really want to get arrested, with weapons, murder, torture, etc... being involved.

That's also the reason why mainstream apps like Signal are important for privacy, if only criminals use an app, having that app is a legitimate reason for being suspected. If most people using the app don't really need privacy and it is mostly used to talk about what to eat for dinner, that protects those who really need that privacy. And yes, it includes criminals, unfortunately, so it is actually a good thing for society when criminals use their own communication channels instead of using mainstream ones, good thing most of them are not so smart.

And it failed at it too.

People who buy trucks as a status symbol want to be "tough". And Tesla clearly intended to appeal to "tough guys", it is big, powerful, and supposedly indestructible. Elon even twitted at some point that it would destroy the other car in a collision, a morally questionable comment, but the implications are clear, a though vehicle for people who don't give a fuck about others.

And then, they managed to break the unbreakable window during the presentation, followed by the rusty trucks, and most importantly, the whole fiasco with glued panels that came off. So, you market a tough vehicle, but it falls appart. Who is going to buy that?

I doubt that replacing painted regular steel with fancy stainless steel is going to be cheap. Paint is expensive, but so is stainless steel. I also can't imagine the "origami" technique to be cheaper than stamping, the reason they suggested that is because their fancy stainless steel can't be stamped. And in the end, Tesla couldn't even do it, so they glued the parts on...

I don't know any item where the unpainted stainless steel version is cheaper than the painted steel version, thinking about kitchen appliances for instance. For cars, the most famous car with a stainless steel body is the DeLorean DMC-12, which was notoriously expensive, even without the time circuits.

Well, yes, but it is even more mechanical than this.

Here is the simplified version:

Let's say I have a company worth 1 billion dollars, publicly traded, 10 million stocks worth $100 each. I get promised $100M from the state (aka taxpayers), shareholders estimate there is about 50% chance I will actually get the money: $100M * 50% / 10M = $5. It means the stocks are now worth $5 more, so $105.

Now the government has changed, and gone are my chances to get that money, so the sock is back to $100.

In this particular case, it is type safe. NULL, by the C standard does not refer to an object. It means that every pointer in C is effectively an option type, which mean that a function that returns a pointer can return NULL for "no result", which, in the case of crypt() is perfectly adequate.

It is the opposite that is unsafe, that is, when the returned value can't be NULL, but it stills returns a pointer. C++ has references in an attempt to fix this problem.

Because C tends to prioritize performance over safety, a NULL pointer dereference is considered undefined behavior and the compiler can invoke nasal demons if it makes the code go faster, but with the right options, you can have it checked and invoke what in other languages would call a panic handler, but on UNIX is the SIGSEGV signal. You can then attach a debugger or read the core file and see what went wrong.

Note: I am not talking about "char *" for strings, that one is unsafe, but NULL is not. It is just a special case of an option type, or a result type, or an error union. Modern languages just extended this idea to objects other than pointers, and with more than one type of error.

I think it is much simpler than that.

The Trump administration was expected to invest massively into AI, and money invested into AI is effectively free money for AI company shareholders, that free money is priced in the stocks. With the change in direction, investments are expected to be less, which means less free money, and therefore less valuable stocks.

Verbosity and architectural complexity matter to a coding agent. LLMs have limited context windows, and the less verbose the code, the more you can fit in there.

Complex architectures are even worse, again due to limited context. LLMs work well at the function level but have trouble seeing the "big picture". I would argue that working with agents is all about managing context and things like skills, subagents and the practice of writing plans are just a way to optimize context use. If you could stuff your entire code base in there with full attention, it would be much easier, but the costs of doing this would be prohibitive.

It is technically frontier, if by "frontier" we mean the Pareto frontier.

Being at the Pareto frontier means that you can't get something better on one aspect without compromising on some other aspect. The trick is that it is easy to be at the Pareto frontier by having enough dimensions.

Here, we have 4: score, number of parameters, origin (US) and open-weight. You can get a better score or a lower number of parameters, but you have to compromise on at least one of the other aspects. That's a pretty weak frontier if you ask me.

Bike lanes don't just compete against car lanes. They also compete against sidewalks and bus/tram lanes.

There is also the question of what you are going to do with your bike once you are at your destination, where are you going to park it?

For those who went to Amsterdam as a pedestrian, I don't know how it felt, but to me, it was not great. Lots of narrow sidewalks littered with stuff, the stuff in question is often bikes, so you have to step onto the adjacent bike lane, where you are usually greeted by an angry cyclist, because for some reason, parking your bike on the sidewalk is fine but stepping on the bike lane is not.

So, as a pedestrian, I wished Amsterdam converted its car lanes into trams and sidewalks rather than bike lanes. And yes, I hated bikes for as long as I stayed in Amsterdam, and so did everyone in my group.

The cars vs bikes debate tend to get a lot of attention, but the bikes vs pedestrians and public transit aspect matters too.

Note that bikes + buses can be a particularly dangerous combination. Buses are long and can block off the path of a careless cyclist as they turn, who may fall right under the wheels of the bus.

I use to joke about PHP in the early 2000s, but now that I see the "better languages", I am starting to like PHP.

If you want a web page that works with a database (aka. CRUD), presents it in HTML form, and with a bit of business logic, like 90% of websites, then PHP does it simply. None of these astronautic patterns like you see in Spring, the dependency hell that comes with node, or whatever the cool kids are using right now. There is a reason PHP became so successful despite the hate it gets.

PHP is not great for security, it was terrible when it started, but now it is decent. And sure, a vulnerability was found, it is now fixed, every time a vulnerability is found and fixed, PHP becomes better. New technology may have an advantage due to better design, safer languages, etc... but you shouldn't dismiss the qualities that 20 years of bugfixes get you.

As for x86, yep, it is legacy, but it is not completely stupid either. The "RISC core" is not right, it is not like x86 become ARM or RISC V code internally. It is translated into long microcode-style instructions that wouldn't make sense as an ISA, where a compact representation is important for memory/cache reasons. RISC code is also translated just like x86 code, and the advantage of CISC vs RISC has gone back and forth. Now it seems we are going back towards RISC again, but before that, it was CISC, and before that, RISC again. The quirk about x86 that complicates things seems to be the variable length instructions. But the real problem is not really about which ISA is the best (it is a very small part of modern CPUs), it is more about licensing and backwards compatibility.

The lack of a universally accepted "good" build/module system like npm, mvn, cargo, etc... has the side effect of limiting the tendency of relying on way too many dependencies, and also limits supply chain attacks.

I mean, it is a real problem, it is making life hard on developers for no good reason, but sometimes, artificial friction can work against some anti-patterns. Similar in spirit to "chaos engineering".

LLMs are excellent writers in the sense that they get the spelling, grammar, syntax, etc... right. They are certainly way better than I am, and they can compete with the best writers considering how AI-generated prose has winned literary prizes.

Many people don't like the style, probably by association with slop and fatigue more than the style being fundamentally wrong.

Being a good communicator is an entirely different thing, you can have terrible spelling and grammar and still be good at getting ideas across. It is a common situation when the communicator in question is not using his native language.

That LLMs are so good at writing and so bad at communicating is not surprizing. The key to good communication is getting into the other people's mind, LLMs can't do that, because they "think" in a way that is completely alien to us. We use words to express our thoughts, thoughts that are based on a physical world model: touch, movement, sound, light, etc... LLMs have no idea about how the physical world work, everything the see is just words, they have no intuitive idea of, say, objects falling down, just that "falling" and "down" go well together. And for explaining things, they will go "someone asks for an explanation, explanations usually use these words, I will be using the same kind of words".

No, we are just seeing a push towards Nvidia wanting to make money.

Nothing stops you from giving Nvidia half a million for their latest and greatest AI GPUs, unless you are in China I guess, but China does very well despite the export control.

It is just classic market segmentation, the thing Nvidia and just about every company that can benefit from it has done for decades. Cloud providers are ready to pay a lot of money, consumers wanting local AI have a lower budget, and gamers even lower. But a low budget is greater than zero, and there is still money to be made on these markets. But they also don't want to compete against themselves, so they are going to find ways of crippling enterprise-class workloads on consumer hardware.

It used to be that they crippled high precision arithmetic on consumer hardware, because it was a differentiating factor, but AI doesn't care about high precision, so now, it is something else.

It is a completely different device.

Flipper Zero is for the physical layer: radio, RFID, IR, etc... It is based on a small microcontroller and is mostly "bare metal", think Arduino, ESP32,...

Flipper One is for the network layer: Ethernet, Wi-Fi, 5G, etc... It is a "real computer" running Linux, like a Raspberry Pi.

Done right, cloud backup actually is "the right thing".

There are problems with cloud backups, but they are solvable. One is confidentiality/privacy, that's what encryption is for. The other is that you can lose your data because the could provider doesn't like you, it is a failure mode, in the same way that your tapes can burn. Use redundancy, like with any unreliable storage solution.

With an onsite NAS, local copies and cloud backup, you meet the "3 2 1" rule (3 copies, 2 storage types, 1 offsite) without the hassle of dealing with tapes, and it will probably be cheaper too, unless you are particularly data-hungry.

So, Astra essentially reproduced the abliteration process, but instead of removing refusal out of the system, it removed some looping behavior.

But you must remember at least some events from a long time ago with a lot of details.

And if you wrote a blog, these would be the events you would write about. You obviously won't write a blog post about events you don't remember.

It is selection bias, it is not indicative of the ability of Raymond Chen to remember all little details.

From the point of view of the pay department, maybe. From the point of view of the employee, absolutely not.

It is like counting tolls as a component of "employee compensation" for a driver. An employer may decide to have a driver use toll roads, which may result in faster deliveries and more efficient use of his time. From the employer point of view, he is paying more to get more work done, from the driver point of view, he is paid the same for the same amount for time driving.

The title should be: why is booking one online so hard?

From my experience travelling in Japan, online booking is a mess. But every time, the solution was simply to go to the station, walk to the counter and ask. The guy will get you exactly what you need, may give you alternatives if what you want is unavailable, tell you about unusual connections, take into account whether you prefer to be seated together or if you prefer to leave ASAP. This is real service from competent tellers. And I am saying this as a tourist who practically can't speak Japanese. And for paying, cash always works. Alternatively, if you don't need to talk to someone, there are also some ticket machines that are rather well designed.

It turned out to be a better experience than in most other places that may have better websites and more digital payment options. Yes, you have to physically go to the counter, but the is a good chance you are going to be in train stations a lot, it is not really a problem.

It is millions of time better than some booking websites that are designed to extract as much money as they can from you instead of helping you (ex: low cost airlines). No, I don't want insurance, no I don't want extra luggage, no I won't pay extra to choose my seat, no I don't want priority boarding, no I don't want to rent a car, no I don't want a hotel, no I don't want your app, no I don't want to subscribe to your mailing list, yes, I know what I am not getting, don't try to upsell me a second time, I just want a ticket to my destination!

Top level engineers and other VIPs are people too. And it is often surprising how "low" they can get.

We may imagine the CEO of a large company in his throne room, only reachable through his servant and only for matters of utmost importance, billion dollar contracts and all that. And sure, there is that, but not just that.

You may occasionally find out that the guy who a replaced a defective Ethernet cable on the intern's computer was that CEO. Or the lead developer of a AAA game patiently explaining some basic functionality to a random gamer. A CTO may pick up a random support call. So Raymond Chen debugging an "obvious" problem in a .bat script, not at all surprising to me.

It has already happened to me that on a support call where I expect some underpaid grunt, find that the guy is really good, patient and friendly, only to end up discovering that I just talked to the one who built the whole thing. Makes my day when it happens.

It think that if I was some kind of VIP top level whatever, I would cherish these moments. Simple things, genuine human contact, away from the big responsibilities tied to my position. And even from a professional perspective, getting a feel for what happens down there is important.

Anthropic and others harvest source code from around the internet based on the idea of fair use. The big idea behind fair use is that you are not using the copyrighted material to compete against its owner.

For example, by distributing cracked software, you compete against the official channels, so, not fair use. Quoting a book in an article won't make the people who would buy the book go with the article instead, so, fair use. AI companies argue that training is fair use because their model is a completely different product than what they are scraping. A LLM that has read the Harry Potter novels is not a substitute for the Harry Potter novels.

But all these rewrites make the fair use argument flimsy. These models are used to make knockoffs of the products that are part of their training data set, at least in part. Not fair. It is in their best interest to limit the amount of knockoffs their models are used to produce. Imagine if they had to compensate the people they took the work from...

In addition, if fuels their argument of "we are making sure our models are only used to make safe and innovative content, unlike these bad open models that are used to make dangerous knockoffs".

I don't know if "quick to type" has ever been a reason?

Short words mattered in the early days, with punch cards, very limited memory and computing power, shorter words saved resources. Also, when running a program means handing a stack of punch cards to an operator and waiting for the result to come out the next day, saving a few seconds of typing probably wasn't a priority.

As computer got fast enough not to care about single bytes, there was a push against using shorter names. "be descriptive" they said. Also we had more advanced editors with copy-paste, search and replace, etc... If there was an objection for overly long variables, it was more about screen real estate than typing speed.

I'd say the case where it mattered would be interactive shells, UNIX shells in particular, because for DOS, commands were limited to 8 characters by the filesystem, another technical limitation. But then came completion, making typing speed not really an issue, but you still want to be able to fit your command in one line, because otherwise it is annoying.

So: technical limitation or readability rather than typing speed.

The situation with Google is a bit unexpected.

They have top of the line research, I mean, they invented the thing, and they are still doing stuff that goes beyond making a bigger LLM, as it seems to be the only thing the others are doing, research-wise.

They also have hardware capabilities no one else has, they invented the TPUs, and have lots of them.

They also have the brand recognition, ecosystem, user base and lots of money.

So why are they lagging behind on the actual products, and by lagging behind? I mean they are always in the position where they are just behind the frontier, but still in the game.

It seems almost deliberate. Maybe they are playing the long game, waiting for the bubble to burst. Maybe they don't want to compete against the more profitable parts of the company. Or maybe their researchers are not interested in making an actual product unless being forced to.