darksaints

Yes, I consider Obama to also be to blame somewhat. But in practice, the situation with the 2014 invasion was a lot more complex to respond to. Russia quite successfully obscured their involvement in the first couple of days...all signs pointed to Russia but they denied involvement and the little green men wore no Russian insignia, so it could have just as easily been framed as internal separatist activity, which was the Russian intent. It actually took a couple of weeks before it was crystal clear that Russia was behind everything. By then, Crimea was already occupied.

The war in Donbas was only a little bit more clear. Even though Russia's fingerprints were all over every action there, there was also no doubt that there was significant Ukrainian separatist activity, and even the most resolute of allies will hesitate to defend their allies from separatist activity.

With Biden, we saw the buildup, knew it was going to happen, and had been warning Ukraine that it was going to happen. We saw it for what it was on day one without any equivocation. We just did nothing about it.

I'm gonna get flak for this, but both Trump and Biden are heavily to blame for nuclear proliferation. Trump due to his actions against Iran in ripping up the nuclear deal just because he didn't like the person who negotiated it in combination with his decision to assassinate Soleimani. But Biden is just as much to blame due to his refusal to do anything of consequence when Russia broke the agreements of the Budapest Memorandum. We should have had boots on the ground when they invaded, but we waffled back and forth on selling them 50 year old weapons technology for months and now years. Unacceptable, and now the whole world knows that the major nuclear powers can't be trusted to come to anybody's aid.

I love my device...it has profoundly changed my quality of sleep on the same scale that CPAP therapy has.

Seeing the founder fellate Elon and his Doge employees has given me second thoughts. I may be looking for an aquarium chiller in my near future.

Yes, of course. But apart from the (current) disadvantage that those drivers don't exist yet, those are all positives in favor of microkernel architectures. All of the massive SLOC codebases run in usermode and with full process isolation, require no specific language compatibility and can be written in any language, do not require upstreaming, and do not require extensive security evaluations from highly capable maintainers who have their focus scattered across 40m lines of code.

At this point, even an unverified kernel would be a huge step up in terms of security and reliability.

And the performance disadvantages of a microkernel are all overblown, if not outright false [1]. Sure, you have to make twice as many syscalls as a monolithic kernel, but you can do it with much better caching behavior, due to the significantly smaller size. The SeL4 kernel is small enough to fit entirely in many modern processors' L2 cache. It's entirely possible (some chip designers have hinted as much), that with enough adoption they could prioritize having dedicated caches for the OS kernel...something that could never be possible with any monolithic kernel.

[1] https://trustworthy.systems/publications/theses_public/23/Pa...

Ah yes, thanks for the correction.

The SeL4 microkernel specification assumes the use of a memory management unit, and is required by default.

https://docs.sel4.systems/projects/sel4/frequently-asked-que...

I agree that SeL4 won't replace Linux anytime soon, but I beg to differ on the benefits of a microkernel, formally verified or not.

Any ordinary well-designed microkernel gives you a huge benefit: process isolation of core services and drivers. That means that even in the case of an insecure and unverified driver, you still have reasonable expectations of security. There was an analysis of Linux CVE's a while back and the vast majority of critical Linux CVEs to that date would either be eliminated or mitigated below critical level just by using a basic microkernel architecture (not even a verified microkernel). Only 4% would have remained critical.

https://microkerneldude.org/2018/08/23/microkernels-really-d...

The benefit of a verified microkernel like SeL4 is merely an incremental one over a basic microkernel like L4, capable of capturing that last 4% and further mitigating others. You get more reliable guarantees regarding process isolation, but architecturally it's not much different from L4. There's a little bit of clunkiness for writing userpace drivers for SeL4 that you wouldn't have for L4. That's what the LionsOS project is aiming to fix.

I've been using Linux since 2005, and I've loved it in almost every circumstance. But the drama over the last couple of years surrounding Rust in the kernel has really soured me on it, and I'm now very pessimistic about its future. But I think beyond the emotional outbursts of various personalities, I don't think that the problem is which side is "right". Both sides have extremely valid points. I don't think the problem is actually solvable, because managing a 40M+ SLoC codebase is barely tenable in general, and super duper untenable for something that we rely on for security while running in ring 0.

My best hope is for replacement. I think we've finally hit the ceiling of where monolithic kernels can take us. The Linux kernel will continue to make extremely slow progress while it deals with internal politics fighting against an architecture that can only get bigger and less secure over time.

But what could be the replacement? There's a handful of fairly mature microkernels out there, each with extremely immature userspaces. There doesn't seem to be any concerted efforts behind any of them. I have a lot of hope for SeL4, but progress there seems to be slow mostly because the security model has poor ergonomics. I'd love to see some sort of breakout here.

This was a heartbreaking and terrible read. I've been feeling a bit of disillusionment about linux quite a bit lately, mostly due to bad/weird decisions being made at the distribution level. Reading this extends that disillusionment down to the kernel level.

The problems cited are portrayed as sociological problems, but I really wish people could recognize that all of them can be mitigated, either substantially or entirely, with a single purely-technical solution: microkernels.

* Almost nobody needs to upstream code to the kernel

* Trusted codebase size becomes negligibly small

* Maintenance burden for drivers, subsystems, etc., falls on the users of the subsystems affected, and not the entire community

* Broad language compatibility by service interface instead of ABI compatibility. The need for a singular compiler is reduced in scope down to the size of the subsystem instead of the entire ecosystem.

The biggest problem that can't be solved purely technically is the entitled user problem, but even that is partially solved. This is because the barrier to contribution is substantially lower:

* I can write code in Rust, but I don't know C.

* I can easily write simple drivers for some hardware features like battery managers and fan controllers and temperature sensors, but I don't know anything about kernels.

* I have a lower, but non-zero understanding of security, and would not feel comfortable writing code that runs on ring 0, but wouldn't feel inhibited writing code that benefits from process isolation.

Those attributes about myself inherently mean that for a microkernel OS, I can be a contributor, but for Linux, the best I can be is an entitled user.

I watched a little bit of the filesystems in rust talk and while it was a fairly straightforward talk, I was shocked at the q&a session. Emotionally hyperbolic ranting, jumping to conclusions, and wild accusations. I had no idea the linux community was so childish and reactionary towards rust.

Did that straw man feel really good to hit?

The reason why application of LP in a newish area is not really publishable is because the field of Operations Research has been doing that continuously for the past 80 years. Modeling planning problems as mathematical optimization problems has been done long before computers were capable of solving them, and convex optimization problems in particular have the most historical work put into them, due to early innovations. Optimizing selections of cloud resources in particular is so ubiquitous that those exact types of problems tend to be used as tutorials to get people up to speed for various types of solvers.

Unfortunately we have a very bad branding problem, and almost nobody who hears the name "Operations Research" can infer what we actually do from the name, let alone understand the mountains of research that we've accumulated over time.

I fully agree with this, but the problem with this idea is that if we only ever choose to adopt the most boring mature technology, it doesn't give any room for better to ever exist. Be selective and judicious, but also open-minded and willing to re-evaluate. Sometimes the exciting things are exciting for very valid reasons. I'm okay with hype cycles, even if they are annoying to me as someone who constantly has to justify why I'm not adopting them, as long as they lead to maturation of innovative ideas.

You'd have to be as high as a kite to have any answer for this question other than yes.

The pile-on isn't a coincidence. Forgive me for the tin foil hat, but there was an absolutely massive amount of investment in Silicon Valley coming from Saudi Arabia in the last year, and reading the tea leaves from the public statements of all of the partners of these firms, those investments absolutely came with strings attached. Mark Andreessen and Ben Horowitz, who were both longtime democratic donors but only occasional-endorsers, suddenly announced their support for and endorsement of Trump almost simultaneously with an announcement of $40B from Saudi Arabia. That's just the tip of the iceberg...hundreds of VCs have received funding from SA in the last year, and many of them ended up helping Elon buy twitter and get out of a lawsuit for trying to back out of the twitter deal, and he didn't even have to sell his Tesla stock to do it. Conveniently all within the same month that Elon first met Putin, and first started echoing Putin's "plans" for Ukraine.

It is well known that Donald Trump's deal to sell jets to SA is what elevated Mohammad Bin Salman from Defense Minister to Crown Prince over Bin Nayef. It is also well known that Donald Trump ran political interference for MBS when he had international condemnation for the assassination of Khashoggi...he even was caught bragging about it. And from the best that I can see from the public record, Trump called in all his banked Saudi Arabian favors all at once and Silicon Valley, once the domain of establishment democrats, became the firm territory of MAGA nearly overnight. All it took was money.

I got a false permanent ban as well. Despite the fact that cheating is damn near impossible on consoles, and the fact that I worked way too long to get to an absolutely mediocre rank (gold 1) on ranked play, and the fact that I had never even had a warning or complaint for any behavior whatsoever, they permanently banned me with no explanation.

Unlike the blogpost, I just decided I would just never spend any money on an Activision product ever again. It's what everybody should do.

> You were fine the first 4 years you'll be fine the next 4 years.

No, we were not fine. And that was with a House, Senate, and Supreme Court actively stopping him in every way they knew how. Now he has all of those in the bag and carte blanche to do whatever he wants, and with Project 2025, all of those pesky lifetime civil servants are now blindly loyal political operatives or they are fired. Our society is going to go down in flames.

Ammonia has a lot of uses, and fuel is one of them.

Ammonium nitrate is made from ammonia and nitric acid (which is also made from ammonia). Therefore, ammonia is the only necessary direct precursor to ammonium nitrate, which is probably the most relevant oxidizer in improvised explosives today.

Not saying that it should be regulated on the basis of national security, but it’s not like there isn’t a potential security concern.

Are these really catalysts in the traditional definition of the word? Meaning that the catalyst is non-sacrificial? This appears to be suggesting that nitration can be done with atomospheric N2 simply with the right catalyst. But N2 is triple bonded, and the lowest theoretical threshold to react N2 with anything is by breaking at least one of those bonds, which is incredibly energy intensive even under theoretically optimal conditions.

Some of the most promising research in replacing Haber-Bosch is actually plasma-assisted nitration, which is basically just as energy intensive as Haber-Bosch, but with drastically lower capital requirements...something that could be done in your backyard. I struggle to see how an ATP catalyst-only method could even do anything close to breaking an N2 triple bond.

Pseudonyms are to opinions like incorporation is to businesses. It lets you take a risk without coming back to bite you personally. If you're right (or people like your opinions), you can gain a following with it. If you're wrong, you can always abandon your pseudonym.

I don't necessarily think that's bad. I do it myself, by posting with usernames that are not directly attached to my own. But there is a certain amount of respect that I give to people that do things with their name attached. They take a risk that many in our society no longer do: they put their name and identity on the line with their opinions. Even public figures who are absolutely reprehensible in about every way possible get a tiny bit of respect from me for having their name attached to their shitty opinions.

That was my first impression as well. Unfortunately I grew up with someone who offered "mentoring" when he felt the need to augment his own sense of magnanimity, and the only help that was given was that I needed to agree with his (always bigoted, usually horrifying) opinions about whatever was on his mind at the time. So whenever someone is openly offering mentorship, I immediately nope out.

I don't know anything about the author, but he doesn't seem like a bad person by any means, and this post is probably well intentioned. I just can't help but get an ick from this.

The funny thing about those "tests" is that LLMs are judged by their ability to do that themselves, as opposed to their ability to write code that does it. The best LLMs still fail at doing the task themselves, because they fundamentally are not designed to do anything except predict tokens. But they absolutely can write code that does it perfectly, and can write code that does so many things better than that.

I know future GPU development is addressing the constrained ram problem, but it is nonetheless a massive problem for local inference. MoE seems to solve a compute problem, at the expense of compounding the ram problem. So I have a question... My understanding is that the typical MoE model starts each output token with a decision as to which expert model(s) to send inference tasks to. How often is it that the vast majority of predictions end up being sent to the same expert(s)? Wouldn't it be a more practical from both a training and inference perspective to do the same mixture of experts model, but choose experts on a much higher level of granularity? Like maybe on the level of the whole response, or clause, or sentence? At least then you could load an expert into ram and expect to use it without having to do massive IO loading/unloading constantly.

> Rails is not dead; It's better than ever. Try using it to make something new this year.

Apparently that's one of the few things you can do well with a rails app. As evidenced by all of the rails apps stuck behind 3+ major versions because refactoring or upgrading without breaking everything is damn near impossible.

The last time I used Rust for any sort of project was two years ago, and the code size concerns were one of the first things I thought about when contemplating writing for embedded targets in Rust. Executable sizes were really bad, especially at -O1 optimization levels, but I haven't really seen much of a problem in practice today so maybe they fixed it. From a performance and memory efficiency standpoint, Rust is on par with the C/C++ projects I've worked with. Some things slightly worse, some things slightly better, but nothing egregious in either direction.

I will say that the coroutine-based async facilities in Rust's embedded-hal and embassy-rs projects make task-based concurrency so easy to do with bare-metal code that there isn't much need to use an RTOS in many of the situations that a C/C++ project could do. That sort of OS-less concurrency is no doubt possible in C, but I shudder to think what it would look like.

How do you write a function in C that restricts its parameters at a type level to a subset of an enum's set of values? I'm aware of how to do that at runtime, but I don't think I've ever seen it done at a type level. Same goes for detecting two different usages of a resource at a type level...got an example? I'm not saying you're wrong, just that my beginner level understanding of C has never seen anything remotely close to that, and from my attempt at googling, its apparent I don't even have the right vocabulary to find it.

Admittedly, a lot of this complaint with C/C++ might not be technical but cultural. The pervasive use of macros and templates might have an origins in avoiding some technical painpoint of the languages or compilers, but they have a real effect in how they are used. For example, I didn't know that C had consts until I started reading K&R...real world usages in open source code almost always use define.

And the same goes for rust...for example, the extremely restrictive type system of Rust means that a lot of effort has gone into making type errors extremely helpful, so that you don't end up wrapping your whole program in an unsafe block. In C, you are told that you have a type error, but in Rust, you are told why, and given extra context, and in common cases you are pointed towards what you probably wanted.

I've long been a fan of strongly typed languages, but have settled into using dynamic types a bit mostly for ecosystem reasons. Recently I've gotten into embedded programming and initially my thought was that I would have a much easier time getting into it by learning C and C++ simply because those are pretty well standardized on embedded devices. And it has been so fucking painful. The build systems absolutely suck...cryptic, finicky, and archaic. Small variations in developer environments cause so many errors. The package management is basically non-existent. Maybe you use Boost or a couple other libraries, but mostly you avoid them because the package management is terrible and build systems are even worse. You're basically writing everything from scratch. The thing I overlooked the most though was the type systems. C and C++ are statically typed, but weakly so. And therefore, the thought of using the type system for safety guard rails doesn't exist. You specify types so that programs will compile, and that's it.

In comes Rust. I know the memory management is the thing that sells it, but in an embedded project, I'm simply not doing any dynamic memory allocation, so I didn't think I'd see much benefit. I mostly tried it because Cargo is an amazing build system. But the thing that has sold me on it is the type system. Within my first 5 minutes of porting a magnetic encoder driver, the type system caught an error in my ported code. I used the wrong pin for my SPI MOSI connection to my driver. It absolutely blows me away that the type system knew I was using the wrong pin. Turns out the code I could never get to work in C was broken because I was referencing the wrong pin, and I never knew why. Fifteen minutes later, it caught another error: by sharing the SPI bus, it could identify that there were more than two devices connected, because there were two CS pins declared, and because the device wasn't exclusive, I had to wrap the bus in a refcell for memory safety. Absolutely amazing.

I never thought that embedded programming could be fun, and strong types were what changed my mind.

How long til the us army announces its new contract with Tesla to outfit the whole service with cybertrucks?