Not sure I buy that explanation. Looking through this repo, the kernel, drivers, and many core libraries seem to be written from scratch with no dependencies. There are some deps for reading images, and other things outside of kernel/driver function, but this seems mostly written from ground up (A rust based OS could bind to a C/C++ png or sound file library in the same way).
Writing an OS is a fiddly task to say the least. It's one thing to be motivated to create an OS regardless of language (such as this), vs let's create one to showcase a language. It's harder to recruit people for the latter frankly, and having written OS and kernel code, it's fiddly work that more people talk about then actually enjoy doing it over the long haul.
Also in defense of Redox, I think it has far different goals, rather than getting something up and running with interactivity quickly. SkiftOS is much more "toy"/fun hacking vibe.
> I did fairly deep research on this beforehand, looking into actual pharmacological aspect of interactions with things like dopamine, etc
While you can read about mechanisms and in vitro this and that all day, this is not the same as quality applied clinical research, which frankly just doesn't exist in any meaningful quantity. I am a practitioner, and I am very sympathetic to the movement of alternative treatments counter to established standards of care, however at the end of the day it doesn't change the fact that the controlled research is non-existent or poor, and things like the MAPS manual are essentially woo.
And specifically the problems I have is that ironically, these alternative treatments which are supposedly trying to overcome boundaries of established care are extremely proscriptive themselves.. they're limited, just differently, and the justifications have very little evidence based backing.
That is not how safety margins work. Safety margins are meant to give a buffer for unforeseen circumstances, they are not a ticket to just cheat. With this logic... why stop at a 25A breaker (30 in the US)? Why not just plug a 20A device into a 100A breaker, or no breaker at all?
No safety margin can account for purposeful circumvention, which is what connecting a 15/20A outlet to a 30A circuit is.
There are X server implementations for Windows, Android, AmigaOS, Windows CE!!, etc... I don't think this is relevant.
> macOS has a POSIX layer.
So do many systems, again including Windows in varying forms through the years. I think the salient issue is that BSD UNIX and "tradition" are conflicting. The point of the original CMU Mach project was to replace the BSD monolith kernel.
Anybody long enough to remember Unix from the beginning or even just the last 25 years... which is a tiny percentage of this site... should know that a unifying Unix or Unix "tradition" as noted in a follow-up comment is a pretty much a myth. The tradition is whatever system you grew up on and tribal biases you subscribe to and the only true Unix traditions are mostly trivialities like core shell syntax and a handful of commands, and a woefully underpowered API for modern purposes. And long option names are definitely not part of any tradition.
Myths like "everything is a file" or file descriptor is complete bollocks, mostly retconned recently with Linuxisms. Other than pipes, IPC on Unix systems did not involve files or file descriptors. The socket api dates to the early 80s and even it couldn't follow along with its weird ioctls.
Why are things put in /usr/local anyway? Why is /usr even a thing? There's a history there, but these days I don't seem much of anything go into /usr/local on most Linux distributions.
It's also ironic to drag OS X into a discussion of Unix, because if there was one system to break with Unix tradition (for the best in some ways) -- no X11, launchd, a multifork FS, weird semantics to implement time machine, a completely non-POSIX low-level API, etc, that would be it.
All this shit has been reinvented multiple times, the user-mode API on Linux has had more churn than Windows -- which never subscribed to a tradition. There's no issue of lack of familiarity here, the original Unix system meant to run on a PDP-11 minicomputer only meets modern needs in an idealized fantasy-land. Meanwhile, worse is better has been chugging along for 50 years while people try to meet their needs.
What else do you suggest that is liquid and essentially risk free? There is a purpose for this type of product. If not a high yield savings account, what is it?
For one, having known many posters on wsb personally, the number of people actually trading large positions vs the number participating in that forum is not the same.
Finally, people (apparently even the "informed" crowd here) greatly overestimate the difficulty of identifying individuals or actions in massive systems that are effectively recorded and completely surveilled, and they underestimate the resources of the feds. It's usually not that hard to whittle down to a handful of actions, and even if there are hundreds it only takes a tiny bit of taxpayer money to comb through it by hand.
They have had these for years in OR suites to dispense surgical scrub soap. They use an air bulb and tubing rather than mechanical link since that is much more durable and cheaper to replace. These obviously present an accessibility issue in public places that don't generally apply to ORs. I think the hand operated or IR is the good enough solution in most cases though.
> In reality you'd be one of thousands of people holding HTZ calls or TSLA puts in your Robinhood account. You could make a huge payday and be indistinguishable from the crowd.
Sure it may not be the most critical point about language design, but it's not just bikeshedding either. For one thing, it is a language semantics issue rather than plainly syntax issue.
I still like Lua, and maybe you don't even agree with Dijkstra's argument, which is also possible to make, but doesn't mean its bikeshedding - which seems to be a totally overused term to basically mean any argument I don't want to have.
Frankly, garbage. Serious bakers are capable of a lot more consistency than you realize.
> It turns out that not all eggs are the same.
You can weigh eggs, or more often it's actually sufficient to balance the liquid to offset the variation in eggs -- a lot of baking especially isn't just about taste - but about consistency and proper proportions to get repeatable texture and density. It is also generally speaking quite sufficient to deal with food liquids in volume as well since room temperature differences are controlled close enough such that it doesn't matter.
The difference in weight of a cup of water between 20 C and 25 C is negligible.
1 cup of flour on the other hand can vary in actual material by over 20% because of numerous variables from clumping to type of flour.
> I don’t know how many times I’ve seen someone in a video boast about measuring the flour by weight for their bread, only to add a completely unmeasured amount when flouring the working surface or their hands.
Basically bullshit again because: In most cases, the working surface flour won't amount to even 1% of the final product, however as stated volume vs. weight can make double-digit differences.
Your whole "10 gram" of sugar claim is a straw-man.
Baking and pastries tends to require a lot more precision then basic cooking to get repeatable edible results. It's the one reason why pre-made cake mixes and Bisquik are so popular, even with professional chefs.
The scheduler overhead and the cost of context-switches are vastly overstated compared to alternatives. The per thread stack space in effect has virtually no run-time cost, and starting off at a single 4k page for a stack, thousands still only waste a miniscule about of memory.
401k backed loans are nothing new. The incentive is the avoidance of tax penalties (or less obtusely that's the disincentive at the federal level to just withdrawing). It's not to prevent stock sell-offs, it's to prevent people for whimsically withdrawing from their 401k/retirement account..
Nothing stops your friend from selling everything and leaving it as cash or some non-stock instrument in the account.
> You can even at any point in time stop execution in the debugger, rewrite part of the world and just press continue as if that was how the code was originally written to start with.
Bit of a straw man, because you wouldn't do this regularly in code. Python on the other hand is a relatively large language at this point, and plain idiomatic python code leans relatively heavier on JIT unfriendly constructs compared to the other languages mentioned. Meanwhile, CL has a whole concept of "compile-time" that doesn't really exist in python.
Hence the "perversely" part.
PyPy has used similar tricks as Smalltalk, Self, and JS/V8, many which were old hat in the 90s, but PyPy demonstrates that writing a performant JIT with reasonable memory requirements for real world code is much harder for Python.
> 100% of Python users find it to be fast enough for their use case.
This is unlikely and an odd thing to say especially in the context of a thread about people rewriting their software in a different stack in part because of python performance issues. There are plenty of people using python that feel the pain and need to spend resources on performance improvements.
The fact very many line of business apps will require more and more complicated hardware resources compared to using "boring shit" like .NET or Java, or Go (which is actually pretty boring, startup hype aside). I'm no huge fan of Java, but I don't feel any less productive in Kotlin than I do python, for many things it is even better. Python aside from a few things is still looks like a 1989 language with a few newer features - the language other than being basically binding lazy doesn't have many amazing tricks up its sleeve. Meanwhile 30 years of progress has been rolled into the mainstream of C#, Swift, and Kotlin.
> To compare speed of CPython with quality of anything is such a narrow view
I'm not saying you can't write quality software with python. What I was saying is the only niche that Python has maybe picked up a significant mindshare compared to alternatives is scientific computing. And I say this with no insult, but as a former grad student in the sciences and having written quite a bit of monstrous python - it's not a field of quality software engineering.
> "Make Python faster" is just a losing game imo. It is fundamentally never going to be as fast as other languages, it's far too dynamic (and that's a huge appeal of the language).
This cannot be overstated. Unfortunately python is especially perversely dynamic. After all Javascript and Ruby are highly dynamic, but for a number of reasons have avenues that allow more meaningful optimization gains without changing language semantics. (And although it is true that Google had tremendous resources to pour into V8, it's not like this point doesn't stand - luajit as an example).
Python imho took the performance/productivity trade off way too far. You can get some very effective dynamism with some minimal restrictions that won't so badly shoot yourself in the foot for performance opportunities later. Frankly, for mainstream development, Kotlin or C# gives very pleasant, productive languages with strong ecosystems without paying such a penalty. Swift is good. Go isn't personally my cup of tea, but sure.
Python sort of got a foothold in science.. but that's never been known for being a field of quality software engineering.
> Pointers are an exposure of the underlying computer architecture. Whereas references are more of a property of common language design.
Sorry, I just don't follow. How are the pointers in Go more exposing of the underlying architecture than a reference? (I'm using Go as an example to make it concrete, but any language with similar properties will do).
The syntax and some of the semantics of assignment and rebinding are different between say go pointers and python references, but that's the point I'm contesting, I don't see how one is necessarily higher level than the other. If you put automatic memory management, null pointer checks, removal of any "undefined behavior", pointers aren't necessarily low-level. It wasn't the pointer, it was the memory safety.
I personally think that once you tease it out that it becomes a semantics argument that unfortunately doesn't shed much light on what is "high-level".
You're fundamentally mistaken about where Qt sits in the stack - it effectively sits in the same place as USER32/WinForms in Windows or NS/Cocoa GUI widgets of OSX. It is reasonable to think of it as an alternative native GUI library in that sense. If it is slower, it's because an implementation of something is slower, not because of where it lives or an abstraction cost.
Qt pretty much draws using low-level drawing APIs on the respective platform. And although Qt itself is not written in the most performance sensitive C++, it is still orders of magnitude faster than most (and it's not like Chrome doesn't pay overhead) - people rag on vtable dispatch speed but jeez its still orders of magnitude faster than something like ObjC which served Apple quite well for years.
The performance of a Qt app is more likely a function of the app itself and how the app developers wrote it.
But no, you're not noticing any micro-seconds differences in C++ overhead for Qt over "native native" - and you're basically comparing the GUI code of the platform - since Qt does it's own rendering. Win32 is mostly pretty good, NS is a mixed bag, and Gtk+ is basically a slug. In all cases there is some kind of dynamic dispatch going on, because that is a fundamental pattern of most GUI libraries. But dynamic dispatch is almost never a factor in GUI render performance. Things like recalculating sizes for 1 million items in a table on every repaint are the things that get people into trouble, and that is regardless of GUI library.
Writing an OS is a fiddly task to say the least. It's one thing to be motivated to create an OS regardless of language (such as this), vs let's create one to showcase a language. It's harder to recruit people for the latter frankly, and having written OS and kernel code, it's fiddly work that more people talk about then actually enjoy doing it over the long haul.
Also in defense of Redox, I think it has far different goals, rather than getting something up and running with interactivity quickly. SkiftOS is much more "toy"/fun hacking vibe.