|
Gazpacho posted:If you ever used NT 4 you would know that this was practically necessary yeah, nothing could make that turd feel fast
|
#
?
Mar 28, 2019 19:38
|
|
|
|
| # ? May 17, 2024 06:49 |
|
|
Sapozhnik posted:i mean yeah linux and the whole posix model in general have a somewhat discredited design at this point but fuschia is a land grab and nothing more. it is in nobody's business interest other than google's, qualcomm's, and cell carriers' for it to succeed. i'm not even clear on how it's a win for google writing their own os kernel with its own non-posix interfaces seems like some navel gazing bullshit
|
|
#
?
Mar 28, 2019 19:39
|
|
|
tbf posix is bad
|
|
#
?
Mar 28, 2019 19:44
|
|
|
pseudorandom name posted:tbf posix is bad writing your own process creation / thread management api just means somebody else is going to come along and smear a horrible posix-compatible fork and pthreads implementation overtop it anyway might as well embrace the badness
|
|
#
?
Mar 28, 2019 19:48
|
|
|
fork() is the number one reason why posix is garbage and more operating systems need the courage to acknowledge that fact and move on
|
|
#
?
Mar 28, 2019 19:51
|
|
|
pseudorandom name posted:fork() is the number one reason why posix is garbage and more operating systems need the courage to acknowledge that fact and move on the courage not to be compatible with the software that is already written
|
|
#
?
Mar 28, 2019 19:59
|
|
|
fuschia has the courage to be completely loving useless see also: jony's macbooks
|
|
#
?
Mar 28, 2019 20:00
|
|
|
Sapozhnik posted:"stable kernel driver interface" oh goody i love IHV-maintained drivers that have some mandatory garbage winamp skin interface that marketing says has to show up as much as possible what does a stable kernel driver interface have to do with the rest of your rant for example, afaik those garbage winamp skin uis and updaters you get when installing a wandows gpu driver are separate user space binaries, not part of the module loaded into the kernel im sure fuschia is a land grab but lol if you think a stable kernel driver api/abi is anything more than goog wanting to fix one of the perpetual dumb broken by design linux problems at the same time. it is possible for a thing you hate to not be pure evil in every last detail, you know?
|
|
#
?
Mar 28, 2019 20:02
|
|
|
Notorious b.s.d. posted:the courage not to be compatible with the software that is already written and nothing of value was lost
|
|
#
?
Mar 28, 2019 20:08
|
|
|
BobHoward posted:what does a stable kernel driver interface have to do with the rest of your rant no you dont understand it's really important that i have a REALTEK HD AUDIO MANAGER that looks like it's ready to start playing the motion picture soundtrack from The Matrix pop up every time i plug in an audio device
|
|
#
?
Mar 28, 2019 20:28
|
|
|
making it a pain in the rear end for an ihv to maintain a linux driver that is not part of the upstream project is not a bug, it's a feature. only nvidia has managed to swim against that tide and it's still a giant pain in the rear end for everybody to deal with.
|
|
#
?
Mar 28, 2019 20:30
|
|
|
And by everybody you mean both Linux desktop users I guess 
|
|
#
?
Mar 28, 2019 20:42
|
|
|
Notorious b.s.d. posted:the courage not to be compatible with the software that is already written
|
|
#
?
Mar 28, 2019 21:19
|
|
|
nbsd doing a bit of posting performance art, in derailing the pl thread about linux, the linux thread about rpgs, and, i presume, some games thread somewhere about programming languages (or maybe there is a longer cycle still, i am only seeing these pieces of the chain)
|
|
#
?
Mar 28, 2019 22:05
|
|
|
welcome to yospos take off your shoes stay a while
|
|
#
?
Mar 28, 2019 22:30
|
|
|
pseudorandom name posted:pthreads are the number one reason why posix is garbage and more operating systems need the courage to acknowledge that fact and move on
|
|
#
?
Mar 28, 2019 22:41
|
|
|
Notorious b.s.d. posted:writing your own process creation / thread management api just means somebody else is going to come along and smear a horrible posix-compatible fork and pthreads implementation overtop it anyway You mean 'nearly compatible but with horrific edge cases also the performance will absolutely suck all the balls' hi cygwin
|
|
#
?
Mar 28, 2019 22:56
|
|
|
Sapozhnik posted:making it a pain in the rear end for an ihv to maintain a linux driver that is not part of the upstream project is not a bug, it's a feature. only nvidia has managed to swim against that tide and it's still a giant pain in the rear end for everybody to deal with. Plenty more than them unfortunately, see also basically every embedded gpu manufacturer
|
|
#
?
Mar 28, 2019 22:58
|
|
|
Cybernetic Vermin posted:the philosophy of kernel design often being reduced to "well, we have access to all memory so from here it is just as well we smear ourselves in poo poo and write a monolith in overly clever c and dumb-as-hell assembler" (in this type of conversation if only rarely in practice) is really outmoded security thinking, a case of the old approach of figuring that we'll build one inpenetrable barrier perfectly and attempting any other mitigations is a thoughtcrime undermining the one inpenetrable barrier.
|
|
#
?
Mar 28, 2019 23:30
|
|
|
Cybernetic Vermin posted:(or maybe there is a longer cycle still, i am only seeing these pieces of the chain) sounds like you need blockchain
|
|
#
?
Mar 28, 2019 23:40
|
|
|
Cybernetic Vermin posted:nbsd doing a bit of posting performance art, in derailing the pl thread about linux, the linux thread about rpgs, and, i presume, some games thread somewhere about programming languages (or maybe there is a longer cycle still, i am only seeing these pieces of the chain) threads are merely the canvas for my art 💩
|
|
#
?
Mar 29, 2019 00:34
|
|
|
feedmegin posted:Plenty more than them unfortunately, see also basically every embedded gpu manufacturer mobile gpu drivers are generally complete trash, so i wouldn't count them as a success story having a kernel that's more binary-blob friendly isn't going to suddenly make them not trash or even update more frequently because the problem is the vendors, not the os
|
|
#
?
Mar 29, 2019 02:28
|
|
|
pseudorandom name posted:fork() is the number one reason why posix is garbage and more operating systems need the courage to acknowledge that fact and move on please elaborate I have no idea what you mean by fork sucking
|
|
#
?
Mar 29, 2019 05:48
|
|
|
Janitor Prime posted:please elaborate I have no idea what you mean by fork sucking it doesn't work well with threads at all, it's racy, it's a bad way to launch subprocesses because there's no way to control memory behavior, leading to things like the oom killer
|
|
#
?
Mar 29, 2019 05:53
|
|
|
Suspicious Dish posted:it doesn't work well with threads at all, it's racy, it's a bad way to launch subprocesses because there's no way to control memory behavior, leading to things like the oom killer like so many other parts of unix, fork was good in its original context (the early 1970s, hackers having fun making an os for themselves) but isn't aging well
|
|
#
?
Mar 29, 2019 06:25
|
|
|
it's elegant only if you ignore everything else about operating system design. see also: plan 9
|
|
#
?
Mar 29, 2019 07:03
|
|
|
Notorious b.s.d. posted:the courage not to be compatible with the software that is already written fork() is low level enough that you’ll mostly wrap it in real world use those wrappers can just switch to posix_spawn(), as long as you also have enough extensions to cover the behaviors it doesn’t specify the number of times you want an actual clone of a process is vanishingly small
|
|
#
?
Mar 29, 2019 09:32
|
|
|
Janitor Prime posted:please elaborate I have no idea what you mean by fork sucking fork clones a process, including not just its file descriptors but its address space too in large systems that work with a lot of subprocesses, this can be extremely expensive, and you wind up with hacks like forking once to exec a tiny binary (to throw away all that address space that was cloned) that then forks and execs a bunch of binaries posix_spawn for all its warts is a great replacement because it creates a process anew, with a bunch of stuff set up for it however you request (especially with extensions), making it so much cheaper for the common case
|
|
#
?
Mar 29, 2019 09:44
|
|
|
BobHoward posted:like so many other parts of unix, fork was good in its original context (the early 1970s, hackers having fun making an os for themselves) but isn't aging well it really wasn’t, a spawn API would’ve been better even then it was a cute hack to make process creation “copy on write” but it’s not a great tool even on something like a PDP-7 or PDP-11 there’s a good reason BSD added vfork()
|
|
#
?
Mar 29, 2019 09:47
|
|
|
JawnV6 posted:they're still using overly clever c and dumb-as-hell assembler tho yeah, my complaining applies equally to most that favor microkernels, because they too have a really olden idea of the design space. apropos for the thread is mostly that better languages, associated primitives, and tools are obviously called for, and specifically the microkernel side has subsumed a lot of thinking about proper architecting but then also chained that work to a few failed core ideas. BobHoward posted:like so many other parts of unix, fork was good in its original context (the early 1970s, hackers having fun making an os for themselves) but isn't aging well mostly it was good that it was quite light-weight, so a lot of the useless semantics it offered could just be ignored as they didn't cost much anyway. really though a lot of syscall design is akin to cisc instruction sets where they assume a lot of complexity to make things seem conceptually easy, where very very few programmers in reality ever call them, and they should probably always have been a more orthogonal collection of primitives. the windows 10 pico processes + pico providers (where process creation is basically just creating a memory map, you get nothing mapped in and no thread created, but you get hooked to a chosen kernel-space "provider" which controls how those things can then happen) is a pretty neat model and should probably have been in there day 1.
|
|
#
?
Mar 29, 2019 10:56
|
|
|
Janitor Prime posted:please elaborate I have no idea what you mean by fork sucking a lot of the things that make Unix a broken shitshow are boneheaded design decisions that got codified into mandatory standard behavior or deliberate design choices made to keep backward compatibility with Unix's stone age origins e.g. there's nothing inherently wrong with signals, Windows demonstrates how you can implement them properly -- SEH behaves like C++ exceptions and APCs don't have unmanageable global handlers and only get delivered at specific points when the application is blocked waiting for event delivery or ELF symbol lookup semantics, for example. ELF dynamic linking was designed to be a drop in replacement for static linking behavior, and the end result is you get random symbols name collisions from random libraries. OS X started out with this idiocy, but they switched to two-level symbol namespaces almost immediately. there's no reason for Linux to be stuck with it other than laziness and inertia fork on the other hand is a fundamental design flaw. there's no way to design a quality operating system that has fork, because fork absolutely requires you to do stupid things. e.g. if your 200 GB database process wants to create a child process, it has to fork and then exec. when it forks, you have two choices -- either you duplicate all 200 GB of your database, which requires you to have 400 GB of RAM in your server (and you can cheat with COW to make this "fast" because you only end up duplicating a handful of pages, but the 400 GB bookkeeping requirement is still there) or you lie and implement overcommit, in which case you've designed your operating system around heuristically killing random processes to free memory when your lies catch up with reality and you run out of RAM. either way is a lovely design. and that's just the fundamental inescapable problem with fork, Unix has codified a bunch of boneheaded design decision on top of fork related to what else gets duplicated into the child process along with the address space and basically everything is a buggy mess as a result
|
|
#
?
Mar 29, 2019 19:24
|
|
|
Athas posted:It would be great if I could mount dubious USB filesystems in userspace, but for the big filesystems (like /) a crash is just as bad as a total kernel panic, because it's not like I'd be able to continue working, and I might lose data. Same with a crash in the display driver. isn't this what libfuse does, for filesystems? also i think the display driver thing is actually in use by multiple OSes. they kill and restart the display driver if it starts acting up
|
|
#
?
Mar 30, 2019 00:39
|
|
|
pseudorandom name posted:and that's just the fundamental inescapable problem with fork, Unix has codified a bunch of boneheaded design decision on top of fork related to what else gets duplicated into the child process along with the address space and basically everything is a buggy mess as a result correlation/causation much? pretty sure everything would be a buggy mess even if the os was not a pos, op
|
|
#
?
Mar 30, 2019 01:10
|
|
|
posix is a security nightmare because everything lives in a global namespace and access control within that global namespace is discretionary (i.e. if a process has access to a particular resource then it is difficult in general to prevent it from sharing that access with an unauthorized process). containerization and namespacing are hacks to sort of fix that in linux while retaining posix compatibility. a non-backward-compatible os designed today would be capabilities-based: every process in the system is started up by a supervisor process that passes it the capabilities ("file descriptors") to do its job and there's no global namespace for it to nose around in or exfiltrate things through. a web application that listens on http, talks to a db server, and writes logs would have no way to even get to the filesystem if it were compromised. all it can do is dequeue incoming stream connections, open database connections, and emit logs. https://bus1.org/bus1.html imagine if this was the only system call interface that existed and you wouldn't be too far off
|
|
#
?
Mar 30, 2019 01:19
|
|
|
that sounds like a nightmare of incompatible interfaces but also pretty cool
|
|
#
?
Mar 30, 2019 01:31
|
|
|
Sapozhnik posted:posix is a security nightmare because everything lives in a global namespace and access control within that global namespace is discretionary (i.e. if a process has access to a particular resource then it is difficult in general to prevent it from sharing that access with an unauthorized process). containerization and namespacing are hacks to sort of fix that in linux while retaining posix compatibility. you just described a microkernel
|
|
#
?
Mar 30, 2019 01:43
|
|
|
pseudorandom name posted:you just described a microkernel
|
|
#
?
Mar 30, 2019 01:52
|
|
|
mystes posted:Uh, wasn't that exactly what this discussion was about? yeah, but looping back around to the beginning but citing Bus1 as the example is an odd choice
|
|
#
?
Mar 30, 2019 01:55
|
|
|
microkernel or not is an implementation detail. hurd is a microkernel wank exercise and it also implements posix with all the badness that entails.
|
|
#
?
Mar 30, 2019 03:31
|
|
|
|
| # ? May 17, 2024 06:49 |
|
|
JawnV6 posted:"oh my gosh, latency matters??" - every microkernel ever At least as far as academic microkernels go, this is probably why synchronous IPC benchmarks (measured in clock cycles OF COURSE) are the single differentiating factor
|
|
#
?
Mar 30, 2019 19:18
|
|
