catblast

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.

> XQuartz if you want it

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.

> you're doing it wrong.

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.

This is utterly clueless.

In the context of language design, the arguments for 0-based indexing rise above bikeshedding. https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...

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.

There's a relatively old FOSS "band-in-a-box" program: https://www.mellowood.ca/mma/

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.

Unsurprisingly it is Williamsburg, Brooklyn or close to it.

> 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".

If you're using KDE, Qt is "native native".

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.

The difference between pointers and references can easily become muddled. If you have a language with pointers that are non-nullable, type- and memory-safe, is that not high-level?

I think a good real-world example that exposes the problem in your definition is Go. Go has pointers, using them is normal. However, go does not pointer arithmetic and outside of unsafe (like Rust) they are memory safe. I consider golang to be higher level than C/C++ for this reason, and many others (GC, channels, defer, etc, etc) -- I'd also consider it lower-level because of its non-answer/cop-out to error-handling.

But what is special about pointers compared to references? If you have a language with pointers that are type-safe and memory-safe how is this distinctive?

Building on X gets you very little other than compatibility with the X ecosystem - something that had little to no value to Apple - they certainly didn't want to promote OSX as some kind of Xserver in place of writing quality Mac apps.

Note that with current X, HiDPI and multi-monitor and tear-free experience still have problems and they are handled via a morass of legacy extensions of varying design quality (this is aside from the drivers issue)-- when OS X was started, none of these existed except maybe DBE and a nascent RANDR (there was no COMPOSITE, no RENDER, RANDR vs very primitive), I think there was the Xinerama crap that no one uses anymore because it is terrible.

So they would have had to develop that, for what benefit? What does X get you out of the box? A drawing model that was outdated even by 1995 standards. And network transparency? Everytime these discussions come up, somebody brings this up, and I wonder what drugs they are on. The love by some for the X network model has always baffled me, because it is terrible - it has virtually no practical usability for modern drawing models and compositing, and the worst is it isn't robust - lose your TCP connection, goodbye session! X hits #1 and #2 of the "Fallacies of distributed computing" pretty hard.

RDP, VNC, SPICE are what we use today, for very good reasons.

Actually at first I thought idiot was a bit harsh.. but then I reread what I had forgotten about that post - I think if he's juvenile to promote the vandalism of wikipedia over a completely fantastical, out of context reinterpretation of history to label Thomas Edison a "douchebag", well then it is fair to label him an idiot on a limited forum.

Also, there's no accounting for taste but I find even his non-serious comics puerile and not terribly funny - pretty much one step above Taboola chum, or Jim Davis for millenials. Most of the "humor" and overplayed hook is simply describing everyday things with odd adjectives, ie hair cave=vagina, saliva=evil mouth juice, wow. There's probably a term for this trope.. Anyway, it gets clicks on Facebook.

I hear them if I concentrate to isolate the voices out of the music. And you can pick up on quite noticeable flaws, especially in cadence and intonation. What somebody described as vocal fry sounds more like synthesis artifacts. The bare samples further on the page also highlight issues in cadence.

This is obviously an early demo, but this isn't yet to the level you could narrate an audio book - those little problems will quickly become noticeable.

Good for a beginner effort, but its not really all that convoluted or obfuscated. The problem is that 90% of the obfuscation is in the removal of whitespace. Pretty print the final thing, and it isn't so bad (the 2nd to last listing is pretty easy to follow). Things like 0-1 or 13*1 + 3, etc add some noise but are not particularly hard to parse or understand, the ternary is ugly but it's sequential so nothing up the sleeve there, the memcpy are just a noisy one character assignment. The author should review the IOCCC submissions posted earlier. Like holloway.c.

The thing that's a little different about Tesla in the US at least, is he is so incredibly fetishized by eg high-profile idiots: https://theoatmeal.com/comics/tesla, or conspiracy nutjobs like the International Tesla Institute (http://teslatech.info/ttevents/prgframe.htm http://tesla.org/tesla_fair_abq.htm) publishing and promoting Tesla related conspiracies and hawking investments in snake-oil technology like Rand Cam engines, VMSK, and all manner of "over-unity" machines

So what? Even weather cameras need deterrence from vandals.

Lol what is this? Who made this and what is its purpose?

Bitch has a common use/definition that is not vulgar.

No M is for meta. These names predate X let alone XFree86 by many years. The names don’t even come from a Unix system. Even GNU emacs predates XFree86 by 6 years.

Your writing implies that Emacs is something like the notepad of Ubuntu. But it’s history is much more extensive than that—- which happens to be one of its unique selling points.

Anyway the point regardless of historical context, is that for all sensible people, that capital C is being used as an abbreviation for the word Control. You’re just being a prat correcting people. You’re not even technically correct, you’re just wrong.