I'm taking a look through DOSUTIL.ZIP and I love all these simple elegant C programs. A lot of these programs somehow only manage to have 1-2 standard c #include lines. How often do you see that? I also love how, out of 20,000 lines of C code, there only exists 24 #if statements. This is how C programming was meant to be. Reading codebases like this is one of the things I drew inspiration from when I started working on Cosmopolitan Libc.
Ahh geez. I see stuff like this going on in the background and I wonder what I'm even doing in my life, pushing pencils in comparison to actually, truly solving problems.I'd love to tackle more stuff like this, but I feel trapped chasing what I need to pay the bills (said pencil pushing).
At the same time, companies seem so quick to layoff that I question how I even grow to the point where I'd be trusted with such problems. Do I really just need to do a 2nd full time duty in the open source community to get that growth?
The perpetual inner turmoil for talented engineers :). I accepted a while ago that there's more to life than coding and career, so I don't do much outside of work - 40-50 hours a week of engineering is enough for me. But I try to focus on getting the best job possible that fits what I like to do.
Obviously spending 20+ hours a week on interesting OSS is going to get you more interesting roles over time, and generally OSS stuff is way more fun because you can pick what interests you. But you have to decide if it's worth the cost - do you really want to spend 60 hours+ a week just doing coding / engineering? Maybe you do, but in that case you'd probably be doing it already.
I rarely write code after work for my own use. or others. I spend time with my family. A family that started by me realizing there was more to life than billing clients 14 hours a day.
It's ok to not be building some new thing in your off hours. That's a choice they made for their own reasons. Doing what you do is also a choice and both are valid.
I've definitely thought about it and I imagine it's my end game. But I'm hesitant if I'm truly ready and have the right skills for that. Would that self growth be better than contributing to something larger first (perhaps building more connections on the way)?
There's Many intentions behind it. In rough order of importance;
- working on a medium-large repo size exercises more skills than just jumping into anything alone. Growth is my biggest factor for the next few years.
- OS introduces me to a community of passionate devs. Who can be anything from mentors to expand my horizons, to friends to future contacts.
- I'd choose to contribute to tools I would probably use for my own projects. So I can dig into repos early and know it intimately for the time I'd need to branch for my own project
- potential clout in certain communities can open other doors.
- Resume material is never bad if everything else falls through
It's not my end game but I think it'll help in many ways. And Personally I always had a certain respect for the OS community and want to give back, and hopefully pay if forward. .
I'll keep that in mind. Maybe it will be yet another venture of "I want to connect with people but no one else does" but nothing ventured...
And it would be a soul crushing world if I simply submitted to the fact that we're more connected than ever, but simultaneously I can't find literally anyone else to connect with without money being involved. I have at least a good decade in my heart left to fight that mentality.
That's the hopeful end goal. I unfortuntately need a lot of time and learning to make a product worth paying for, though. being self-sufficient is liberating but terrifying unstable in the beginning. Need to establish proper safeaguards first.
If you are not living the life you want then you are a failure. Face the reality of your situation. While others do what they want you do what you are "supposed" to do, and you know how this feels. Good luck.
> If you are not living the life you want then you are a failure.
What a rude and profoundly dumb statement. Are all the ones who bust their arses out of necessity failures or do they simply want to endure pain? Caring for a handicapped child, parent, being trapped in a poor country, etc.
I'd be curious to know where most of you around here who put desires above all else are coming from.
I don't understand where you are coming from. I've met cab drivers in the third world that are successful, because they live the life they want. I've met investment bankers in the first world that are failures, they are rich but can't do what they want because "N reasons", trapped as you put.
A parent that cares for a disabled child is only a failure as long as he does not want to do it but has to. In this case he is not only a failure but a horrible person.
I volunteer to care for old people 1h per month and I do not consider this a burden or entrapping or nothing like that. In fact I've met my first wife like this.
> A parent that cares for a disabled child is only a failure as long as he does not want to do it but has to. In this case he is not only a failure but a horrible person.
> I volunteer to care for old people 1h per month
I'm sorry, it does not render what you're doing irrelevant, but the comparison is laughable.
Caring for a disabled children is a full time job. I can't imagine that most were hoping to be in that situation when they conceived. It doesn't prevent them from being good carers for the child they love. If you meet some of these parents, ask them. Then you can tell them they are horrible people because as opposed to them you voluntarily go to chat with an oldie for 1h a month.
>A parent that cares for a disabled child is only a failure as long as he does not want to do it.
I’ve seen the parents of severely disabled children. The daily work, financial cost, and social cost is immense. They don’t give up their children often out of duty and sympathy not because they ever wanted to live a life like that. They are burdened and entrapped and it’s not simply a matter of mindset.
Not even the disabled children would be keen to agree with you that their self-sacrificing parents are failures and horrible people if they feel they’ve been burdened and entrapped. THEY feel burdened and entrapped themselves. People in a bad situation can sympathize with people’s circumstances for what they are. They might resent the parent being open about their feelings, but not for having them at all.
As for why the 3rd world cab driver does not feel this way, a cab driver in the third world is often doing relatively well compared to their peers, they may have grown up in worse circumstances, and cab driving is something relatively easy to give up for a few years and then pick back up no worries. That’s not nessecarily true of the investment banker or the parent of the disabled child.
I agree with that, and I am comfortable with the prospect of others not putting themselves first, therefore opening up the possibility of them putting my interests first.
>If you are not living the life you want then you are a failure.
"For what it’s worth... it’s never too late, or in my case too early, to be whoever you want to be. There’s no time limit. Start whenever you want.... I hope you live a life you’re proud of, and if you’re not, I hope you have the courage to start over again."
My courage definitely wavers, but the stuff I'm "supposed" to do will hold me back if I try to what I want first. If I can't do that first, I'll at least set the breadcrumbs as I climb out of that pit.
Here's an alternate framing for you: if you are living the life you want, then you are a failure. You have settled, you have ceased to strife, you're no longer growing and evolving and aspiring.
It's a condition of certain kinds of life, to tolerate unbearable dissatisfaction. Many things have come from this drive, many astonishing people have shared it, and they'll never settle. They'll die still not 'done', their dreams unreached… because those dreams were able to scale, those stars remained beyond their reach.
If you're going down that route, make sure to take a look at this source file for it[1], which is an absolute work of art not just for the code but for the artistic presentation, including elaborate inline logos.
> In the above one-liner, we've basically reconfigured the stock compiler on Linux so it outputs binaries that'll run on MacOS, Windows, FreeBSD, OpenBSD, and NetBSD too. They also boot from the BIOS. Please note this is intended for people who don't care about desktop GUIs, and just want stdio and sockets without devops toil
they also boot from the BIOS.... does this mean that I can achieve my dream of booting straight into a BBC BASIC emulator on bare metal(ish)?
Can cosmopolitan replace the whole llvm toolchain required by GraalVM’s native-image? Currently cross building with native-image is a pain, especially compared to golang. (Or resource intensive as you need to compile it on each platform/architecture you want.)
It’s probably not the best form to abstract away the OS-distinctions, as every abstraction will hide important details from the underlying OS. E.g. certain JDK native methods could be more efficiently done for, say, windows, then through a libc-like abstraction library.
cosmopolitan.h is a concatenated rollup of hundreds of header files, shipped as part of the "amalgamation" variant of our release, and those sub-headers had #ifndef _FOO_H guards at the top and bottom. The rest of the #ifs are required by standards so we don't clobber the user's control of their namespace, e.g. `#ifndef _GNU_SOURCE`. What you won't see is the annoying stuff that checks for CPU, OSes, endianness, etc.
In fairness, my understanding is that APE manages that by making the differences invisible to the application. I'm not sure whether that makes it more or less applicable. (More impressive, obviously, but not simpler)
We can still get away with those sins today if you change C's implicit type from int to long. I modified chibicc to do just that it was a 1 LOC patch. Suddenly I didn't need prototypes anymore and everything just worked without #include lines.
> C99 requires that you at least declare a function before calling it
Where is that written? Please quote the standard. My reading of ISO/IEC 9899:TC3 is that Foreword says (paraphrasing) "hey, we removed implicit int and implicit prototypes from the standard". So they simply stopped specifying it, but as far as I can tell, the standard says nothing about forbidding them. From my point of view, that means compilers are free to still implement implicit types as a compiler extension to the language, and everyone does, because that extension is needed in order to support the older c89 standard. It would only impact people who want to be able to claim their codebase is c99 standard compliant, because you can't do that if you depend on compiler extensions.
ISO/IEC 9899:TC3 [1] §6.5.1 ¶2: "An identifier is a primary expression, provided it has been declared as designating an object (in which case it is an lvalue) or a function (in which case it is a function designator)."
There's even a footnote to underscore this point: "79) Thus, an undeclared identifier is a violation of the syntax."
Prototypes are required in C23 as part of the expungement of K&R syntax. This also brings harmonization with C++ where an empty parameter list is implicitly void.
But why does it have to be that way though, can't the compiler scan the rest of the code/files and see if a defenition/declaration is present somewhere?
There is no such requirement of a declaration before first call in Java for example?
I suppose you could just create a ".d" file standard that doesn't have that requirement but processes into a ".c" file that has the necessary prototypes. You could probably also auto-insert all the #if'n'def nonsense automatically and skip it in the ".d" files.
Kind of like how the JavaScript dudes all use this ".ts" stuff now for convenience that processes into ".js"
Just to be a little picky, but if you want “convenient” then just stick with pure JS - it’s overly forgiving and simple. TypeScript is lovely and I much prefer it over JS, but having to type _everything_ is far from convenient imo
It is! I’ve been working in an environment that essentially requires us to type as we code (rules against using the “any” and “unknown” types) that in just used to them being enforced now lol. So I suppose my point is moot, as the tediousness isn’t forced by the language necessarily.
The Arduino build system does this (preprocesses your source code to pull out prototypes and put them at the top). To make things easier for beginners.
Prior to C99 (i.e., in C90), there was a rule that any undeclared identifier id that was followed by a function call parenthesis would be treated as though there were an implicit declaration in the scope in which it was used like this:
extern int id();
The empty parentheses meant it could take any number of arguments, since it was declared in the traditional style, where the argument types weren't specified first.
This implicit declaration meant that if it was later defined in the same file as returning a type other than int, the compiler wasn't permitted to go back up in the file and treat the function call as though it returned a type other than int.
This requirement was removed in C99, but in practice, compilers kept doing it for backwards compatibility, even when not invoked in C90 mode.
What I understand is the preprocessor causes issues where you could do that maybe 99.9% of the time, especially with well written code. But it'd fail that 0.1% of the time.
You do have analyses like ctags. In theory the compiler could use ctags to find definitions in source code. My experience is ctags can get confused. It's possible in a set of files to have multiple implementations of a function and ctags can't tell which one is used. And I see cases where it can't find definitions.
Personally I'd be happy if the compiler tried to find a missing definition using ctags and issued a warning.
I have wondered if adding funct, public, private keywords to the language might allow the compiler to reliably find function and stuct definitions in source files.
The fact that I'm calling a function, it must exist, otherwise the compiler will throw an error ("undefined reference to function"). So forward declarations is just needless typing.
> The fact that I'm calling a function, it must exist
That's not necessarily true. It's possible that the symbol is a function pointer; calling a function pointer requires slightly different code generation. Compare the generated code between:
In practice, it's probably a function, and that's what the compiler assumes if there's no declaration to go off of. But we all know what happens when you make assumptions.
no they are not.
but
>The fact that I'm calling a function, it must exist, otherwise the compiler will throw an error ("undefined reference to function")
you mean the linker will throw an error. The linker is trying to link together the "references" be they forward or backward, that the compiler has created, and the compiler needs to have generated the right references, round peg round hole, square peg square hole.
You don't want your linker throwing errors, it doesn't have the context the compiler does; and you don't want to turn the linker into ChatGPT that can converse with you about your source code, just use the C version of forward references which are not particularly forward, they just say "I don't know where this is defined, it's just not defined here, but we know it's a square peg"
For example, there are architectures where space is tight (embedded for example) and nearby things can be called more efficiently than far away things, so the compiler needs to generate as many near calls as it can, falling back to far away when it has to. It doesn't know in advance how far away things are going to be, but it might uncover plenty of near things as it goes. Square pegs, round pegs.
when you recompile your project code, the library code, is not necessarily around. When other people recompile their library code, your project code isn't around. What's the size of what's being put on the stack? Still gotta get the square/round pegs right.
In which case, it needs to keep parsing the include tree until it finds it. I know why it exists. I’m just not happy about duplicating code. Other compilers are smarter than this.
The thing I hate about this is that it really has no idea what a “public” header is. If I have it on I’ll use something like uintptr_t and get a random include for <__bits/std/uintptr.h> or something that I don’t want. I assume there’s like some manual auditing one can do to go “don’t peek through stdint.h” but either nobody does this reliably or it doesn’t work.
I haven't looked that deeply, but I don't see many sins in this source code, either, except for the K&R style, weird formatting and doing too much in one line, like this line in the file CAT.C:
if(*(Ptr = argv[i]) == '-') {
Older C compilers did let you get away with more, like using integers as pointers, and dereferencing pointers as though they were struct pointers when they aren't. But I don't see that in this code.
The "sin" I was referring to was calling undeclared functions -- which is how there are so few #include directives in much of this code. Most of the files I looked at include <stdio.h> (probably required for variadic arguments on printf-type functions) and <file.h> (for the FILE type), and call other functions blindly.
That does make sense. My bad, I should have looked closer and noticed the implicitly defined functions.
It's not even a good idea to do that on modern computers, because implicitly declared functions do type promotions from float to double and char/short to int, and on the System V ABI, it has to pass in the number of floating point arguments there are in register eax.
It's not a good idea to do that in production code. FTFY. If you're writing research, experimental, or one-off programs then it can be a real productivity boon. I say do it for fun. You have a right to enjoy yourself and it'll still come out 10x more readable than Perl at the end of the day, let's be real.
>Older C compilers did let you get away with more, like using integers as pointers
In older C compilers (maybe pre-ANSI, or later, can't remember), you could literally write i[a] instead of a[i], where a was an array and i was an int, and it would work equivalently, i.e. no compiler error, and give the same result as a[i]. This was because a was the address of the start of the array, and i was an offset, so a[i] actually meant *(a + i), which, by the commutative property of arithmetic, was equivalent to *(i + a), which was equivalent to i[a].
I had read this in some C book, maybe K&R or the Waite Group C Microsoft Bible.
Never forgot it, because it was counter-intuitive, unless you knew the above reason.
And tried it out in one or more C compilers at that approximate period, and it worked as stated.
This is still true, and it's mandated by the ISO C standard that a[i] is equivalent to (*((a)+(i))) (yes, they specify it with that many parentheses). You're still able to compile code that treats a[i] and i[a] interchangeably.
There’s a lot of distance between “reinvent the wheel by implementing all your network functionality using nothing more than sockets” and “download 100 libraries to serve a file over http”.
There’s a happy medium to be had.
I’d also disagree this is not at all a language problem - I think it’s both, in that the language has moved an awful lot of core functionality into the crate ecosystem, where there are a bewildering array of options for almost any need. The resulting explosion in the dependency graph is an entirely foreseeable consequence — partially of that language design decision and partially due to the “npm culture” (for lack of a better description.)
Slighly off topic, but... how is npm culture different from CPAN culture? I have a feeling there is a difference but I'm too unfamiliar with both ecosystems to point it out.
Speaking as someone who used Perl pretty extensively back in its heyday I’d say the difference is CPAN modules were much more likely to be self-contained, or contain a handful of external dependencies, and those dependencies were almost always self-contained.
Aah, that makes a tonne of sense. When you develop an application you're free to pull in any libraries you want, but the libraries themselves should be more careful. For them, it might be worth reimplementing some essentials.
Sure, if you are putting in a health check and nothing else, that's fine. When you need to parse headers, negotiate content types, validate maximum lengths on requests, properly log the source of the request (it's not just the connecting IP if there's a load balancer in front of it), parsing request bodies, dealing with range requests, authentication, cookies, providing a good middleware mechanism...
The list goes on. While I'm not a Rust developer, there's probably hundreds of libraries because the problem is structured into a lot of small parts, and frameworks are expected to be able to satisfy the functionality you expect without needing to bypass it.
As a security engineer it is still usually cheaper to write specific functions I need for highly limited scope applications than pull in libraries I have to review, and review every update to, forever.
I've seen this attitude before. In that specific case, someone tried to not depend on the signal_hook crate and manually (unsafely) implement signal handling… without knowing that there's a ton of pitfalls to it.
The person you are referring to was likely also me. I do not know of anyone other than me trying to code defensively against supply chain attacks in rust. It is a lonely corner.
I ended up going with sigwaitinfo since the attempts you likely saw on matrix which is perfect for my application that will only ever run on modern linux kernels.
Combining that with the stdlib health check above and we end up with a dead simple health checking signal handling service pattern that works well and easy to confirm is free of supply chain attacks.
While we’re making laws, we could add one where, if someone posts something even slightly critical of Rust, the first couple of responses will be from Rust apologists either: a) pointing out how wrong the criticism is, b) how the criticism is mis-directed and shouldn’t be aimed at Rust, or c) how the criticism is really a beneficial and well-thought-out feature, but under absolutely no circumstances admitting that there might be anything wrong with Rust.
Justine, you are one of less than 5 programmers that make me feel envy. Hope to have a coffee or a whiskey with you some day if we ever cross paths. Enjoy your day, you are an inspiration and goals. Both mental goals and presentation goals, which is essentially unheard of.
Because there were barely any libraries to include back then. If you wanted some functionality, you wrote it yourself. Which was fun, but most of the code pales in comparison to modern libraries that have had years, or decades, or eyes on them improving and testing them. Pre 2000, if you wanted some specific capability, you wrote it yourself!
Looked through the Linux kernel and I was genuinely shocked. Something so simple, easy to read, and improve upon. Makes modern web frameworks seem like spaghetti code. Art vs scrap.
- True=7 -
Having lots of very low-level code and hardware experience, I developed a bit
of tendancy to "minimize what can go wrong at low levels" - C treats 0==FALSE
and !0==TRUE - most people use 0/1 ... but thats only 1 bit "difference". I
sometimes use 7=TRUE as thats 3 bits with no more chars to type (and of course
foolish as such a 1 bit hardware error would "trash" pretty much any system -
but I do tend to be a creature of habit :)
I have never heard of this convention before! Was "random bitflips messing with your conditionals" a common problem back in the day?
Even if it was, are you really going to think of every conditional as a tri-state boolean?
Or will you assume that one of the branches is safe to execute during failure?
Or will you count the number of bits in each conditional and assume more ones than zeroes is a true, with no error correction? Will you log that a bit has flipped or otherwise alert the operator? Will you consider that as evidence that an int has changed value too?
Will you store ints with three bits per bits also?
Error detecting codes have their place, but it takes more than just saying that true is 7.
No, and the author basically admitted it was silly. My counter would be that it makes the intent less clear. I loved reading through his style doc though and I love that he just threw all this stuff out there. Something in his collection is bound to scratch somebody’s itch.
tangential to 'how can a bit be wrong', when trying to see if a serial data line is working, i write 0xA5 ( 1010 0101 ) to send an alternating bitstream with a twist so i can test the greatest number of things i think can be wrong at once
Yes, AA and 55 are common test patterns for a variety of hardware.
Haven't seen A5 in the wild but I suppose it could be useful as a initial "Let's setup a connection" where endianness is unknown. Assuming the next thing that is exchanged is an endian negotiation.
I like to have several sequential ones. Easier to see on the oscilloscope. (I spent last night getting a microcontroller to talk to a SPI device, so I'm still licking my wounds.)
How would a HNer who's not familiar in those nether regions of computing, but wants to feel the excitement of sending a bitstream over a (possibly faulty!) serial data line, get started? Two Arduinos and a cable maybe?
Personally I would recommend finding fun or useful projects where you have an outcome you really desire. Start simple - one sensor like a bath overflow warner (arduino is good or maybe raspberry pi).
Learning hardware just for the sake of it is tough to keep motivated and perhaps you would never use the skills you learn? Hardware adds a tougher level to debugging - but software experience gives you a fantastic start - a logical mind and rational drilling down.
If you can fix your car you have the skills to start on electronics!
A lot of skilled people grew up through the hardware generations e.g. I began learning basic electronics because on an Apple ][ everything was simpler and we were all at the same stage. My first job was writing low level serial driver code and regularly dealing with serial devices (e.g. on PC). Our modern context is just not the same. The internet is hard to learn from. It is difficult to write good articles to help - the experienced like me just know a huge variety of implicitly learned knowledge.
I suggest you concentrate on a useful or fun outcome - I believe it's good life practice (and good engineering) to stay focused on the outcome and not get too side-tracked by explicitly trying to learn. We implicitly learn just by doing!
>If you can fix your car you have the skills to start on electronics!
I'd like to think that this is a comment on the ease of fixing cars, rather than a comment about how fixing cars is basically embedded hardware/software dev....
i was sending pixel data out from an Arduino (ESP32 really but using Arduino IDE) to a bunch of shift registers that seemed to be 74x595 (but couldnt know for sure) to resurrect an LED display for a local art project, and reading the data coming back out from the last register let me know I was at least getting back what I was putting in, which helped me troubleshoot a few wire length and speed/stability issues
The way that really clarified things for me was buying a 3d printer(an Ender 3 for me) and a Raspberry Pi. Setting it up and flashing a new OS to it should basically teach you the rudimentary workings of the hardware->software interface.
I would suggest to search for "Arduino starter kit" or "embedded starter kit" on Amazon. They come with lots of components and usually with some project guides.
To the degree that you were worried about such things, this wasn't a real answer. Yes, it saves you if you have a boolean variable... maybe?
if (var == TRUE)
; // It was 7
else if (var == FALSE)
; // it was zero
else
??? what do I do here?
And you need to solve that "what do I do here" for every single conditional on a boolean, and have the extra lines of code to handle it and not crash.
But, you know, what if it was a variable that you used in a switch statement instead? Or just "if (i > 17)"? Bit flips can affect your logic all over the place, not just when it's a boolean variable.
And then, if a bit flip can affect a boolean, it can also affect a pointer. Or the return address on the stack (or the link to the previous stack frame).
Or it can flip a bit in the code.
So this is, at best, a very very partial solution, and it's non-trivial to implement. So this was very much not standard practice or a "convention".
I've been on a team trying to argue that exact thing. If you aren't going to handle the case where the var is neither true nor false, at least by explicitly documenting the fail-safe case, you're just cargo culting. You get a lot of that type of thing in MISRA and automotive codebases.
Any team that realizes that the compiler may choose to optimize out a shit-ton of such code gets an extra gold star.
Why do you think you need the “else: ??? What do I do here?” case?
Until you added the 2nd test and the 2nd else case, there is no scenario under which both paths of an if/else would fail to execute due to a bit flip of the test variable, because with ‘if (boolean_condition) {} else {}’ there is only 1 conditional test. A bit flip could have caused the wrong branch to execute, but it could not have skipped both branches. A bit flip could change the jump instruction to something else, but in that case your imagined else case still wouldn’t help.
> this is, at best, a very very partial solution
FWIW, the author said this, and fairly succinctly, saying this TRUE=7 thing is “of course foolish as such a 1 bit hardware error would "trash" pretty much any system”. He was only having a bit of fun that cost nothing, and nowhere suggested this is a solution to cosmic rays or other data errors.
The BBC micro and Archimedes used -1 as true in BASIC.
It meant that you didn't need the distinction of "logical operators" (like && in C) and "bitwise operators" (like & in C). You could just use bitwise operators, e.g. the bitwise NOT operator would convert 0 (all bits clear) was -1 (all bits set) so there was no need for "logical operators".
I always felt that was more elegant than C (but of course required a two's compliment machine, which BBC/Archimedes was, but C didn't require).
This is only sound if you have a boolean type that guarantees that the bits are either all zero or all one. Once a mix of bit values is possible, you have to define whether it mean true or false, and then you can’t use the bitwise operators anymore.
No. Random bitflips (aka hardware that doesn't work) are a relatively new thing.
Bit flips due to buggy software was a thing though. This is why most database engines checksum the payload data even in memory. I've also seen network packets corrupted because a bridge (former name for switch) trashed data in flight, then reconstructed its CRC for the corrupt data on the onward leg.
I beg to differ. Early 90s there were some Amiga memory expansions that would constantly flip bits. I'm pretty sure it contributed to the sentiment that the system wasn't the most stable, although I'm pretty sure one or two of my friends with PCs saw similar issues on their machines. Maybe Microsoft Word wasn't to blame for all the crashes?
Of course, trying to work around it in software is utterly futile.
Bitflips aren’t a new thing. I’ve been rarely but painfully bit by them since at least 1986. This. Excludes serial and modem communications where it was a way of life.
SEE/SEU are not a relatively new thing. However, the frequency of events is inversely proportional to the feature size, which has been decreasing over time.
> Random bitflips (aka hardware that doesn't work) are a relatively new thing.
I thought they (from cosmic rays, etc.) were always a thing, but so rare that you needed a very large system (in scope or time or both) to have a substantial chance of encountering one (outside of noisy comm channels, which use error correction protocols for exactly that reason.)
Some event (unknown) triggered multiple spikes in the "tell me three times" redundant three ADIRU units of Qantas Flight 72 causing a WTF unscheduled sudden and dramatic pitch down
Cosmic rays were suspected but unconfirmed (kind of hard to confirm after the fact).
"All the aircaft in the world" for sixty years is kind of a large system given that currently there are on the order of one million people in the air at any moment.
There are lot‘s of thing that can go wrong beyond cosmic rays. Like timing on the bus or signals from close wires. Digital is an abstraction of an analog and chaotic reality.
I’ve been involved with systems where 0xffff… was canonical “true”, but not something as specific as 7! If you’re going to turn on more bits, why not all of them? Though I think this was because the NOT instruction was used for logical inversion, so the bit flip theory doesn’t apply.
For example, the value of Visual Basic's "True" keyword is -1. This seems silly from the perspective of a C programmer, but -1 (0xffffffff) is "more true" than 1 because every bit is true, not just the LSB. :)
Even in VB there is a grain of rationale .. I never even considered before WHY it was -1.. I always just thought it was VB doing VB, but now I have gained +1 respect for Vb..
Luckily it doesn't happen THAT often. I forget the exact metric but I recall various Google Engineers saying that something like one out of a million test run failures is a random bitflip?
Cosmic rays were a theory in 70's era hardware for failures that ended up being proven to be particles emitted by the ceramic packaging itself. (Modern bitflips are have more to do with component sizes several orders of magnitude smaller.) (edit: not saying that cosmic rays aren't a problem now, just that they only became a problem as chip element sizes shrunk, and they're probably not the only source.)
Also, you can definitely stop cosmic rays, that was part of how they eliminated them as the source.
ECC RAM is for the most part relegated to server-grade components, for what it's worth. So your phone, your laptop, your router? Almost certainly not using any ECC RAM, unless you've gone out of your way to do so.
> I have never heard of this convention before! Was "random bitflips messing with your conditionals" a common problem back in the day?
Due to RAM/CPU failures? I don't think so (though I have seen it, fwiw). With weird serial protocols that don't have proper checksums/digests, running over sketchy wiring? Yeah, and that might be part of "very low-level code and hardware experience".
This doesn't make any sense even if the system isn't trashed.
If 7 == true and anything other than 7 == false, then one bitflip will still change the meaning. If 7 == true and 0 == false, then you could have code that does `if (mybool == 7) { ... }` and later `if (mybool == 0) { ... }` and end up with a situation where code path invariants are broken (i.e. mybool is neither true nor false.
If you use `>= 7` to mean true and `< 7` to mean false, while a 0 false value won't randomly become true if one of 3 bits randomly flips, a `7` true value will become false if any of those bits flip. And if any of the other bits flip, 0 will become > 7.
I regret not archiving my early code for good so much. First non trivial program (a snake game). First utility in assembly. First device driver (for a Centronics printer). That perpetual calendar in Pascal for a uni assignment, written with enormous hangover within an hour and still my only program written entirely bug-free to the date. All seemed trivial and not worthy of preservation then but in the end I have no code surviving from before late 1990s.
This is a problem only we'd to face. Kids these days use Git in some hosting hub or the other that it's a rarity that their code gets lots. Of course if these "free" services go down... it matters. Self-hosting has its uses.
I lost the first 5-6 years of code thanks to an IBM Deathstar[1] when I was 20.
Got really depressed by it at the time, as it included most of the projects I worked on at the time. After that I got super paranoid about having backups.
I do enjoy going back and looking at the code I still have though. Being self-taught it's mostly not terribly great, but I do have fond memories of finally cracking a certain nut or figuring out some neat trick.
Left all backups at a remote storage facility. Remote storage facility called me one day and said all of your hardware and media has been lost, except for this one [insert oldest most worthless computer of the bunch]. Cue me raging, cursing out this storage facility, threatening to never communicate with them ever again. Finally accepted the fault lied within me. Up until yesterday, I only had redundant storage but no true backups. So I purchased an LTO-5 and now I have two backup sets onsite and a third offsite at my colocation facility.
In this story the remote storage facility was my mom's house shortly before the GFC. The hardware were varying PS/2 computers from 286 to 486s with hard drives of zip files of my QBASIC, TurboPascal, Delphi, and VisualBasic code. The only hardware saved was our first computer, an 8088. All because she didn't want the clutter in the house anymore. No contact, no chance to retrieve said wares.. just poof gone. Gone were the Z80 ASM files of my rendition of PunchOut for the Ti-83+. Can't reference my old writings that I saved in various TXT files on the gazillion 3.5" floppy disks I kept in an old laundry basket. 5.25" floppies of DOS installs, random games, and an ancient version of SCO Unix. Gone.
Mine did vary quite a bit within that period, from BASIC in middle school to some funky selective availability GPS handling prod code. But it's beside the point: I'd love it as memento, no expectation really that said game of snake would end up on Steam.
Same here. I made a DOS spreadsheet program (with modeX charting! And formulas), a couple of games and a couple of viruses (aaaa TSR looked like magic)... I think they might be in some floppies in my mom's basement.
That was intense. It made me think about my father in law, who had a heart attack in 2015 that compromised 90% of his heart. His exams are so ugly that one of his physicians refused to threat him, probably worrying that he might die any minute during the appointment.
He is still alive today, he has a normal life and he even manages to go for a run in the beach every saturday. His exams haven't improved, he is always out of breath, but he just refuses to die. It's like what the physician said in the link above: "You look a lot better than what's in the paper".
> "Hug his children. Sleep in his own bed. Eat his meals. and Work a little with his hands." in her words "They shot everything she said down"
Anyone know why doctors do this? They did the same thing with my father when he wasn't getting better (leukemia with pneumonia) and they couldn't get him off the breathing tube. They were very adamant he'd be disabled for life.
It's tough. A vast majority of the time the doctors are right about recovery, and the family is wrong, and optimistic to a delusional degree. It's hard work telling family how bad things really are.
Still, if something happens to me or loved ones I hope I get doctors who can distinguish between zero and one in a thousand.
I mean they're giving the best information they have. Sometimes it's wrong, but unless you think they should hedge more (which people also hate, "Why won't doctors ever commit to something, it's always 'maybe' or 'I don't know' or 'we'll see', what's the point of the degree and the high pay if they don't know anything?!") I don't really see what else they can do.
We hear a lot about all the times they're wrong, because they're tragic or frustrating or confusing, and because biology is super non-deterministic they're probably wrong more often than say physicists, but they're also right a lot of the time too, enough of the time that we consider it worth having them. We just don't get as many articles and anecdotes about a doctor correctly predicting someone's disability, because it's not as interesting.
doctors are all completely insane and should never be trusted. the process of getting into and through medical school has a selection bias towards type-a sociopaths. and whoever makes it through that wringer and gets board certified has to be constantly on guard for malpractice lawsuits. half sarcastic but mostly i do believe this lol
I love this. It has crossed my mind more than once to do something similar at some point in the future.
This is a bit like receiving an inheritance from your grandparents. There will be true gems and novelties mixed in with a lot of knick knacks and rubbish. But the totality of that tells a story of real people living rich and interesting lives that only a handful of highlights would not do justice to.
I can definitely relate to this feeling of "when $this is all over, I'll open source a bunch of it, but it's too much work to factor it out now," where $this is more often a company or project than a career.
Sadly, it almost never happens. It just goes to show the importance of open sourcing what you can, as you can (in other words, "now or never"). But it's a lot more work to do that than people imagine, even when they say "well just release it in the least polished form possible." You've still gotta deal with adding a new boundary to your codebase, which not only requires additional effort but also increases complexity of the wider project and makes it impossible to refactor without first refactoring a cascade of miniprojects you've created within it.
I often think of source code like moulding clay. While you’re actively working in a codebase, the clay is moist and malleable. Making changes is easy, because the context of what it does, and how it’s organised is fresh in your mind.
But if you move on to another project and let time pass, the clay dries out and becomes brittle. When you open the project up again, it takes time to “wet the clay” - and remember all that context that you’ve forgotten. It’s easy to add bugs, or reimplement methods that already exist somewhere else under a different name. But over time, you work water into the clay and it becomes malleable again.
I agree with your comment. Refactoring software to split out libraries that you can opensource is a lot of work. More work than people realise. But if you think refactoring is a lot of work when the clay is wet, it’ll be many times harder if you let the clay dry first. Refactoring as you work is always the best way, because it’s often the only way to get it done.
I wish I had saved something from my 40 years of programming, but I alwayds left everything behind when I moved to a new job. I did manage to keep my commercial memory allocator from the late 90's (single threaded, only supported Metrowerks CodeWarrior and the old MacOS), it was the fastest allocator on the Mac, and bug-free, but became obsolete with MacOS X. Not sure anyone would care today. I lost my source code to Trapeze as I mentioned yesterday ( https://en.wikipedia.org/wiki/Trapeze_(spreadsheet_program) ). I guess I never throught about saving most of my work for a day when no one cared if I shared it.
This is really cool. It seems very 'pure' in comparison to what my code history will look like. In 2040, a lot of my code will show how I used a bunch of libraries and frameworks that nobody uses 'these days'. This doesn't seem good or bad, just a reflection of the times.
And unless you put in the effort to archive those dependencies yourself, nobody may be able to truly read or build your code anyway.
Today’s trendy development practices are shockingly ephemeral and fragile. Very little of today’s projects would survive one decade left fallow, let alone four.
A few years back my office threw away a PC running Windows XP with no service packs. It was left in a closet for many years just in case we had to fix a bug in some safety critical code.
A few years ago we tried to rebuild some safety critical code from sometime back and were unable to because the certificates had expired and so the machine that can build the source code refused to connect to our version control system.
This is why I really like Debians policy of being self-contained, that everything in Debian is built from sources that are in the Debian system.
It takes a lot more effort to package stuff, since you can't just download your dependencies from the internet. But you also create something that isn't as ephemeral.
Reading this thread makes me think about archiving my code too. I have backups of my project folders going back to the 90s when I started programming. But I often delete node_modules and other build artifacts before archiving because that stuff takes up so much space.
But maybe it’s worth going through and actively and explicitly downloading all those dependencies too. Who knows when npm will get hacked again, or old package versions will get yanked. Disk space is cheap. I’ve written a lot of code over the years. It would be nice to know it all still runs.
I think that's somewhat the curse of technology. It's so hard to make anything from scratch. How do you get metallurgy working without already having metals? How do you get electricity running without an outlet, or at least powerful, easily sourced magnets?
Thinking about the "dependency tree" for any modern convenience is truly staggering. I can't even start to think about how you can make a factory without first having a factory.
Even before... Trying to compile archived versions of the python 2.7 runtime on recent Linux distributions is an exercise in frustration. Thank god for the gentle souls that keep putting out lightly updated compilable 2.7 python runtimes, your efforts haven't gone unnoticed.
I have a directory full of prebuilt wheels for the entire dependency chains of several python applications I use. All you need to do is tell python to build all the wheels and save them to X directory, and point it back at that directory for installing.
In particular on Termux, there's a number of rarely-used python programs that have native dependencies, so I store them on my network drive to free up storage on my tablet. I have a similar setup for doing stuff on Colab.
It's entirely possible to use python/pip in an offline environment, as long as you've planned for it ahead of time; all you need is pip and possibly wheel, and the correct version of python.
Node predates npm. All node does is look for dependencies in the nearest node_modules directory. (And all npm does is download dependencies into that folder). So you can simply archive / check in your node_modules directory if you want to. I think there’s tools to help out and make sure the dependency versions are all pinned. (npm shrink-wrap and friends)
Vernor Vinge's A Deepness in the Sky depicts a human society thousands of years in the future, in which pretty much all software has already been written; it's just a matter of finding it. So programmer-archaeologists search archives and run code on emulators in emulators in emulators as far back as needed. <https://garethrees.org/2013/06/12/archaeology/>
You've made a contribution to the hoard that someone will benefit from, whether tomorrow or in 5,000 years.
The part about the modern (read: far future) calendar being commonly thought to be based on mankind's first moon landing but ACTUALLY being based on the Unix Epoch is a favorite amoungst engineers I know that love Vinge
This is brilliant.. It's so interesting too because over the years I've built up a few "Bibles" that I always need on hand when working in a particular language or even just automation, I've learnt some very good organising processes (from HN to be honest), I never thought to 'release' them as they feel quite personal and specific for my mental process.
Looking through some of these though, I think I'm inspired. Super cool idea, I would donate to the retirement project financially to say thanks if possible.
I have quite a few of these bibles too. I'd love to swap some files if you're interested, I'm sure there is much to learn from yours. My Gmail username is the same as my HN username if you are interested.
Ah but when you say “bibles”, what do you mean exactly? Is it just common/useful code you fold related to a particular language/framework? Could you elaborate on this
Usually there's a getting started section, mostly links to important nuances in the fine documenting and short code examples. Then there will be a section for each problem that I've encountered - often things that I've solved by reading Stack Overflow answers. But then there are the footguns and pitfalls - this is where the real value of these files lie.
I like to download images of old programming CD's from archive.org, like Programmers Heaven[1] for example. All small and interesing programs/tutorials to look at.
Another link from DDS is Dave's Old Computers http://dunfield.classiccmp.org/ , a nice treasure of old pc reviews and images, (Left, right, front and back). This is amazing as I've been working on making 3D assets for a project of mine.
elvis70 are you Dave Dunfield (the source author)?
[It might be more a ShowHN if you are?]
I'm interested if all of the code is self-written? If you wrote any of it under contract and so had special terms to allow you to eventually release it? Which piece of code there that you are most proud of and/or gonna most useful?
If you're the author, please please release into the public domain (CC0) if your purpose is educational. That makes it so anyone can learn from it and build on it without any fear of infringement.
Though because that license says "for any reasonable purpose" it's something that's vague when it comes to "is this FOSS" as it's vaguely Crockford-like ("this software shall be used for Good, not for Evil").
> 6. No Discrimination Against Fields of Endeavor
> The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
So honestly I didn't read the "COPY.TXT" .. I wouldn't expect a license to sit there, and I didn't consider that a license personally, I was expecting a defined license.
If you're alluding to COPY.TXT meaning COPYRIGHT.TXT and therefore it would/should contain a license then I hate to disappoint you. Copyrights and Licenses are different things. So maybe put a dampener on your expressions of incredulity, it's not a great way to engage here.
