|
This is not a coding horror, rather a horror from a coding textbook. An excerpt from my intro to OSes class textbook:quote:ASIDE: GREAT ENGINEERS ARE REALLY GREAT Yes, feel sad if you don't happen to be one of the few people with the time, money, and safety net to spend all day and night programming poo poo for months on end on the off chance that what you produce can be sold for a profit. Yes, Mark Zuckerberg is definitely a once-in-a-lifetime genius and not just a rich rear end in a top hat who didn't have to risk anything to spend all day programming his product. This textbook is written in the most insufferable, halting nerd-syntax and also has frequent footnotes just for the sake of making Star Wars references and putdowns on people who don't immediately understand the material. If you find yourself typing the word "thusly" as frequently as this book does, you need to hire a technical writer to clean your poo poo up.
|
# ? Feb 4, 2015 18:34 |
|
|
# ? Jun 8, 2024 09:24 |
|
LeftistMuslimObama posted:This is not a coding horror, rather a horror from a coding textbook. An excerpt from my intro to OSes class textbook: What the hell book is this, "OSes for Dummies"?
|
# ? Feb 4, 2015 18:36 |
|
If only we had 12 fingers so that we could have 144x engineers.
|
# ? Feb 4, 2015 18:37 |
|
csammis posted:What the hell book is this, "OSes for Dummies"? Yeah, name and shame please.
|
# ? Feb 4, 2015 18:43 |
|
csammis posted:What the hell book is this, "OSes for Dummies"? http://pages.cs.wisc.edu/~remzi/OSTEP/ Edit: That's right, there's Socratic dialogues in this thing. And the characters all talk like they're in XKCD or something. double edit: Professionally I am a technical writer, so I get really cranky whenever they put a diagram 3 pages away from the text it discusses, or an aside box in the middle of a sentence. They do it A LOT. I offered some feedback on it and was met with extreme hostility. The MUMPSorceress fucked around with this message at 18:46 on Feb 4, 2015 |
# ? Feb 4, 2015 18:43 |
|
Wow, my condolences. That sounds completely insufferable. If you're interested in an OS textbook that isn't self-absorbed bullcrap, I liked Modern Operating Systems by Tanenbaum or Operating System Concepts (the dinosaur book)...but this was 10+ years ago and maybe the modern editions are also written for children by children
|
# ? Feb 4, 2015 18:51 |
|
Skuto posted:Meanwhile, in embedded (really, Android) land, we discovered a vendor has been shipping drivers that try to load firmware...using a relative path...while being loaded in the application context. Ahh vendor drivers. I had to fix a vendor provided gps driver that wasn't even parsing nmea correctly, and had at least 2 (maybe 3, been a while) thread lock potentials due to not using mutexes anywhere in the driver.
|
# ? Feb 4, 2015 19:00 |
|
LeftistMuslimObama posted:This textbook is written in the most insufferable, halting nerd-syntax Is Steve Klabnik one of the authors, by chance?
|
# ? Feb 4, 2015 22:18 |
|
Bonwick is a badass, though.
|
# ? Feb 4, 2015 23:04 |
|
LeftistMuslimObama posted:http://pages.cs.wisc.edu/~remzi/OSTEP/ I skimmed through the book's online version and the dialogue stuff is limited to the introduction for each major section. These "Dialogue" sections look pretty much optional to read, not like there's important information tucked away in there that you wouldn't find elsewhere. The rest of the book seems pretty normal and fine to me. My best guess is the authors read something like "A Play on Regular Expressions" and thought they'd imitate it. At least their missteps are limited to clearly marked sections of the book you're free to skip.
|
# ? Feb 5, 2015 02:53 |
|
Subjunctive posted:Bonwick is a badass, though. No doubt, I just object to literally telling your students that some people are just full stop better than you and if you're not that great you should just give up and feel sad. Deus Rex posted:I skimmed through the book's online version and the dialogue stuff is limited to the introduction for each major section. These "Dialogue" sections look pretty much optional to read, not like there's important information tucked away in there that you wouldn't find elsewhere. The rest of the book seems pretty normal and fine to me. A skim can't really show you this book's problems. The authors have no idea how to construct a sentence, they're constantly putting "aside" boxes in the middle of sentences just for the sake of having them at the beginning or end of a page, they frequently put diagrams pages away from the related text, and there are literally footnotes all over the place that are just lame jokes. All of that is super disruptive and prevents you from absorbing the material because you're constantly being disrupted by bad writing or layout. I'm probably hypersensitive to this stuff because I write technical documentation for a living (at least until I finish this class and jump ship to dev dreamland), but these are really basic things that any editor would point out to them, but it's pretty clear that they haven't had it edited at all and are pretty opposed to receiving feedback.
|
# ? Feb 5, 2015 06:13 |
|
LeftistMuslimObama posted:No doubt, I just object to literally telling your students that some people are just full stop better than you and if you're not that great you should just give up and feel sad. Yes, that is objectionable and the only moral thing to do is object. I could not agree more, I just think Bonwick is a great dude who doesn't get enough appreciation. (FWIW, I think Bonwick and Zuck would both object, though I don't know Bonwick as well.) Subjunctive fucked around with this message at 06:39 on Feb 5, 2015 |
# ? Feb 5, 2015 06:36 |
|
csammis posted:Operating System Concepts (the dinosaur book) This book is pretty crap. It's the typical American textbook; totally stuffed with irrelevant material and written in a very bloated style, and containing many obsolete and pointless algorithms. I have actually heard good things about the book LeftistMuslimObama is slamming, although mostly from the point of view of technical information and basic didactic structure (viewing an OS as a set of abstractions). I can easily believe the editing is poor, as it seems self-published. There are not many textbooks describing modern operating systems design. The best way is probably just to write some kernel code and see for yourse.f.
|
# ? Feb 5, 2015 07:23 |
|
quote:TIP : GETTING IT RIGHT (LAMPSON’S LAW) loving laffo. Any OS engineer could be able to tell you why fork() and exec() are bonkers insane.
|
# ? Feb 5, 2015 08:51 |
|
Suspicious Dish posted:loving laffo. Any OS engineer could be able to tell you why fork() and exec() are bonkers insane. I would like to know more.
|
# ? Feb 5, 2015 09:15 |
|
Well, first of all, COW means that the kernel needs to overcommit memory on fork();. By default, the kernel makes a good assumption that the fork(); will eventually exec();, and assumes that very little of the memory of your original process will actually be copied, so it does a compromise and allows other processes on the system to use more memory than it actually has. This leads to the OOM killer and killing random processes when the system has actually run out of memory. It's also fundamentally the wrong abstraction and has been since the day the concept of multithreading appeared. fork(); will only fork the current thread, so if you have resources (like a mutex) that were managed by a separate thread, your child could hang waiting for a mutex that never gets unlocked, since the other thread holding it doesn't exist anymore. So you're not allowed to call malloc(); (it takes a mutex internally), you're not allowed to basically call anything but setenv, dup, and exec();. I would prefer a system where fork(); took a function pointer, the child process inherited all the VM maps from the parent process but were set readonly, not COW, and the stack page starts empty and fresh. That would allow us to set up the child environment (set envvars, dup fd's) without the giant pitfall that the rest of fork(); has. fork(); is so broken that the original authors ripped it out and replaced it with rfork(); in Plan 9, Linux has clone();, and POSIX specified the mind-blowingly-useless vfork();. But nope, it was a clear example of "getting it right".
|
# ? Feb 5, 2015 09:29 |
|
The idea of just running code to set up the environment of whatever child process isn't a bad one (and there's certainly an argument that it's better than the CreateProcess method of finding some way to specify every possible configuration option you might ever need as parameters), the problem is really everything else involved with fork() (like the fact that it's technically possible to do things other than call exec immediately after configuring the child process). Perhaps a better option would be to just create a process paused, and then manipulate that process object a whole bunch before you actually set it running. Almost like the builder pattern in more enterprisey programming languages.
|
# ? Feb 5, 2015 13:11 |
|
I'm not familiar enough with C to determine if this is a horror, but I think it is. I was browsing the wikipedia page on checkdigits, and under the section for ISBN 10 it says the following: quote:The sum can be computed without any multiplications by initializing two variables, t and sum, to 0 and repeatedly performing t = t + digit; sum = sum + t; (which can be expressed in C as sum += t += digit;) code:
|
# ? Feb 5, 2015 14:44 |
I believe that parenthesizes as: sum += (t += digit) The value of an assignment expression is the new value of the assigned-to variable. So: t += digit reads t, adds digit to it, writes back to t, is an expression with the new value of t And then sum += expression does the same thing, except that here the expression is also an assignment. What might be undefined was if you do something like sum += sum += digit since that assigns to sum twice in one sequence element, meaning the order of the assignments would be undefined. (Sequence element? Is there a proper name for that?)
|
|
# ? Feb 5, 2015 14:51 |
|
Sequence point.
|
# ? Feb 5, 2015 15:11 |
|
nielsm posted:What might be undefined was if you do something like Yeah you're right, this was what I was thinking of. Guess I'm the horror
|
# ? Feb 5, 2015 15:43 |
|
Suspicious Dish posted:It's also fundamentally the wrong abstraction and has been since the day the concept of multithreading appeared. fork(); will only fork the current thread, so if you have resources (like a mutex) that were managed by a separate thread, your child could hang waiting for a mutex that never gets unlocked, since the other thread holding it doesn't exist anymore. So you're not allowed to call malloc(); (it takes a mutex internally), you're not allowed to basically call anything but setenv, dup, and exec();. One of the bigger horrors I've experienced at work (that wasn't code I wrote) was a third party library we use for fulltext indexing. When indexing a certain file type the indexer would hang and two of the processes would show up in the process list. Sure enough, we finally figured out that the library was fork()ing forty goddamn frames deep in the call stack. It seems that the library designers assumed it would only ever be used by a single-threaded parent process and when we changed our process framework to use per-thread mutexes instead of global mutexes then *poof* Naturally the company that created this library hasn't existed for some time and the IP is currently owned by one of our biggest competitors
|
# ? Feb 5, 2015 17:37 |
|
Naive: how do per-thread mutexes work? If only one thread can access them, how do they help coordinate multiple threads?
|
# ? Feb 5, 2015 18:00 |
|
I'm assuming he's talking about separate feeding datastructures per thread with a lock per datastructure rather than a single global lock for "all potentially shared data" or something like that.
|
# ? Feb 5, 2015 19:14 |
|
Skuto posted:I'm assuming he's talking about separate feeding datastructures per thread with a lock per datastructure rather than a single global lock for "all potentially shared data" or something like that. Yep that's right
|
# ? Feb 5, 2015 19:33 |
|
nielsm posted:What might be undefined was if you do something like I don't do this poo poo and am blessed to work with people who know not to do this poo poo, but that poo poo ain't precisely undefined, is it? Someone else might correct me, but sum += sum does not produce an lvalue for += to act upon, so sum += digit needs to be evaluated first, so you'll end up with sum = sum * 2 + digit, right? e: oh no that's right, the right += should affect the left sum as well, producing sum = (sum + digit) * 2. Or something involving void*. Don't mind me, I'm confused. Karate Bastard fucked around with this message at 20:11 on Feb 5, 2015 |
# ? Feb 5, 2015 20:04 |
Karate Bastard posted:I don't do this poo poo and am blessed to work with people who know not to do this poo poo, but that poo poo ain't precisely undefined, is it? Someone else might correct me, but sum += sum does not produce an lvalue for += to act upon, so sum += digit needs to be evaluated first, so you'll end up with sum = sum * 2 + digit, right? Either of these could be a valid rewriting of that expression: sum += digit; sum += sum; or temp = sum; sum += digit; sum = temp + sum; What makes a valid lvalue or not doesn't come into play, the associativity the operators doesn't magically change depending on what would or would not make valid expressions. The assignment operators are always right-associative because that's what makes most sense in the general case. However there isn't any definition of what order the operands of an expression are evaluated in. Two different compilers could generate the operands in different ways. code:
|
|
# ? Feb 5, 2015 20:24 |
|
Suspicious Dish posted:Well, first of all, COW means that the kernel needs to overcommit memory on fork();. By default, the kernel makes a good assumption that the fork(); will eventually exec();, and assumes that very little of the memory of your original process will actually be copied, so it does a compromise and allows other processes on the system to use more memory than it actually has. This leads to the OOM killer and killing random processes when the system has actually run out of memory. why are you putting semicolons after function names like i get using parens to clarify that it is a function instead of an english word, that is a useful convention that i often use myself, but semicolons have grammatical value in english
|
# ? Feb 5, 2015 21:13 |
|
rjmccall posted:why are you putting semicolons after function names if you're going to put the parens throw in the man page section as well
|
# ? Feb 5, 2015 21:19 |
|
rjmccall posted:why are you putting semicolons after function names No particular reason other than force of habit and not expecting people to get mad at it I guess.
|
# ? Feb 5, 2015 22:27 |
|
Suspicious Dish posted:and not expecting people to get mad at it I guess.
|
# ? Feb 5, 2015 23:20 |
|
Yeah, the whole time they were explaining fork and how elegant it was in the lecture, I kinda kept wondering to myself "am I the only person in here who thinks this is really stupid?". Glad to know I'm not alone. I especially loved the part about how great it is that the child and parent are totally sharing the same memory until they aren't.
|
# ? Feb 5, 2015 23:24 |
|
Suspicious Dish posted:No particular reason other than force of habit and not expecting people to get mad at it I guess. It did actually make your post somewhat harder to read; there were several garden paths where the semicolon made sense for a second and then, after the new "sentence" inevitably became nonsense, I had to go back to reread it without the semicolon. I am honestly curious about it; I'm not sure I have ever seen it before. Like I said, parens make sense and are pretty common, but semicolons are new to me.
|
# ? Feb 5, 2015 23:24 |
|
LeftistMuslimObama posted:Yeah, the whole time they were explaining fork and how elegant it was in the lecture, I kinda kept wondering to myself "am I the only person in here who thinks this is really stupid?". Glad to know I'm not alone. It's elegant if you're writing a toy kernel.
|
# ? Feb 5, 2015 23:47 |
|
LeftistMuslimObama posted:Yeah, the whole time they were explaining fork and how elegant it was in the lecture, I kinda kept wondering to myself "am I the only person in here who thinks this is really stupid?". Glad to know I'm not alone. i am writing something right now that uses the linux clone syscall to make a thread that shares memory but not file descriptors
|
# ? Feb 6, 2015 00:01 |
|
Ah, "Get It Right", what a useful, pointless, insulting, tautological piece of advice
|
# ? Feb 6, 2015 01:50 |
|
LeftistMuslimObama posted:Yeah, the whole time they were explaining fork and how elegant it was in the lecture,
|
# ? Feb 6, 2015 02:08 |
|
ExcessBLarg! posted:Are you actually taking Remzi's/Andrea's class, or at least attending Wisconsin-Madison? Professors like to pretend their poo poo doesn't stink, but if this is actually being used at another respectable institution that's insane. I am at UW, but they are currently exploiting the hell out of grad student lecturers in the CS department. The only class I've taken with an actual faculty member is data structures.
|
# ? Feb 6, 2015 03:50 |
|
LeftistMuslimObama posted:I am at UW, but they are currently exploiting the hell out of grad student lecturers in the CS department.
|
# ? Feb 6, 2015 04:41 |
|
|
# ? Jun 8, 2024 09:24 |
|
Suspicious Dish posted:Any OS engineer could be able to tell you why fork() and exec() are bonkers insane. Suspicious Dish posted:Well, first of all, COW means that the kernel needs to overcommit memory on fork() ExcessBLarg! fucked around with this message at 05:17 on Feb 6, 2015 |
# ? Feb 6, 2015 04:58 |