THAT is what would really hurt them. And while it might also slow down the economy for a while, in the long run it would be healthier, as people paid $X for an item, not $X+50% over N years in interest. That interest is money that could be spent locally.
All very well and good, but the point is that it's a lot cheaper (unless you put a value of $0.00 on your time) to just use the "free" windows that comes with your new computer than it is to use Wine, which can't even run simpler games like SimCity2000 (released 1995) without crashing at some point.
About a month ago we had a local manufacturer of cinematographic film abruptly declare bankruptcy and lay off 1,000 people with zero notice. They had completed a change-over to producing the highest-quality cine stock 3 years ago, and RED cameras just killed them dead.
For those wondering what RED cameras are, does 4096x2304 pixels and up, at 48fps, make you drool?
That wasn't a straw man argument, that WAS the argument. Those things you mentioned are the common string functions, not the kitchen sink of string functions. And you're absolutely incorrect, you're wrong as wrong can be.
Common functionality for string classes includes operator overloading, array-like accesses, copy constructors dealing with other objects, pointers to other objects, pointers to c-strings, midstring, substring, trim, index, rindex, cmp, ==, >=, <=, etc. That's a lot more functionality than the basics I wrote about (and if you later find you need it, you can always add it at that point).
Your post makes it clear that you are being willfully obdurate.
As for build times, remember that if you're using the STL (which was the example given), the compiler has to create the templated object at compile time. That's not just "oh, I only need to link to a library". But by the same token, there's no reason that any custom class I write can't be compiled once, and then just linked to, so what was your point again?
The question remains, if you can't write simple classes, why should anyone trust you with anything more complex? And why should anyone have to put up with code bloat, which was the original topic...
In any case, no one could write a complete bug-free string class in 15 minutes which implements everything common to string classes, unless you've got it completely memorized and you type as fast as possible.
Straw man argument. If all I need is a string class that can allocate, free, append, copy and replace strings, I don't need a string class that "implements everything common to string classes".
Also, in custom classes, you're guaranteed that ONLY the code you wrote is compiled and linked to, leading to quicker compiles, and also quicker loading (since there's less need for fix-ups at load time, unless you're already writing position-independent code).
The vast majority of cases are like that - you don't need a "kitchen sink" class, and including all that extra code just gives you more areas for bugs to surface.
If people can't implement (or are afraid to implement) the basic classes that are everywhere, how much can you trust any class they DO implement?
This is where you're waaaaay off. Whereas you seem to think people should implement basic classes that are everywhere, it is exactly the opposite: nobody in your organization should be re-writing the basic classes that are everywhere. They're already everywhere. It's a waste of time... you are going to have to debug and maintain code that you didn't have to before. It's a straw man's argument to claim it's a matter of trust or capability of that they can't write these classes.
Most programmers can't even do fizzbin (or bing, bang, boom, or whatever it's called today). When confronted with a problem, their first instinct is to "solve it with google". If you can't even implement a stack, a linked list, a string class, a queue, or any other basic structure, why should anyone trust you to be able to implement anything harder? These are basic skills for any c/c++ programmer. If you can't implement them, you're really not qualified for the job.
That people seem to think these are "hard" is rather mind-boggling. That it's somehow "wrong" to write the perfect solution for the current problem. 10% here, 5% there, 3% in another place, it eventually adds up. And in some cases, it's several orders of magnitude difference. Example: I implemented the same video routines in both c and assembler. The assembler routine was 200 times faster. Another example - disk reads using c and assembler - the assembler routine was over 50% faster than the drives' rated speed - and a lot smaller. Please don't knock it if you haven't really tried it, because there may come a day when you really need that extra margin that writing your own class provides.
Just because you can't justify it doesn't mean that there are no cases where it's justified.
People have been speaking out against the bailouts for a few years now, and not just the anti-military-industrial-congressional-complex folks either.
Many voted for Obama as a protest against the bailouts. "Main Street, not Wall Street." That was a couple of years ago. That Obama has been a disappointment in this respect is an understatement.
one doesn't need to debug an existing string library.
Oh how naive they are when they're young:-p
When you've been re-implementing the same basic classes for a couple of decades (custom strings, stacks, queues, linked lists, etc), doing it one more time, again customized to your current needs, is really no big deal.
It's not like you need to provide a whole slew of generic methods "just in case" and debug them.
Also, we're not talking c here, but c++ (implementing classes in c is also easily doable, but you have to remember to pass an explicit pointer to this as your first parameter, and manually call any parent classes rather than have the compiler do it for you to implement inheritance).
If people can't implement (or are afraid to implement) the basic classes that are everywhere, how much can you trust any class they DO implement?
Your proposed solution doesn't work because it makes too much sense (and it would be cheaper to just buy a 14 megapixel camera with 4x optical zoom for $99, or use the 5 megapixel camera that comes with your cheapie phone).
Or for under $230, buy a 14mp camera with 22x optical zoom, 4x digital, 16 gig storage, wifi picture transfer, 720p video, 3" LCD viewer, usb, hdmi, batteries, cables and camera bag all included.
Or for $140, settle for 16mp/15x optical zoom, 2.7" display, and only vga movies.
Heck, you can get a really nice 14mp Nikon DSLR with an 18-55mm lens, 1920x1080x24p video, RAW, various memory cards, 3" screen, 1/4000 to 30 seconds exposure, all the usual bells and whistles like auto focus, auto follow, internal dust-off, - just marked down another $100 to $550.00, and if you don't like the lens, you can swap it.
At $3 per color picture for the sx-70 film, it would take less than 200 pictures to make the Nikon free - and you can make unlimited copies w/o degradation.
Yes, the SX-70 was a real innovation for its time... but there's a host of reasons it's dead.
I remember one trick was to stuff code into different pages of the screen buffer and, as each utillity in the chain loaded, execute it if present, and stuff its' values or other code there. Made for a lot quicker than disk access, mimicked overlays on the cheap, didn't use up any "real" ram, and could even (usually) survive a reboot since only the first page got wiped...
You honestly don't believe that handling thread synchronization at container/primitive level is the right thing to do, do you?
No, because not all accesses require that the container be locked, whereas some accesses require that locking be done at a higher level to avoid deadlocks.
Also, I definitely do not believe in SmartPtrs, because they can always be eliminated by looking more closely at the problem. And lets face it - if you're coding in c, you have to go my way anyway, since the STL isn't even available (though you can still create your own "classes" - you just have to pass this explicitly as the first parameter, and you have to explicitly call any parents you want to inherit any functionality from - not a big deal).
You have just described a string class that will result in heap fragmentation and performs horribly under multithreaded scenarios. Well done.
I described the most naive implementation possible, for simplicity. In reality, you normally alloc() a decent-sized chunk, and only realloc() as needed to grow. You can also use that technique to stuff multiple strings inside one chunk. This is an old technique, used by (eg) Borland back in 1995.
Furthermore, if you've spent less than an hour on this, I simply refuse to belive you have the functionality needed for real-life applications, especially not since such a core class should be fully unit tested and documented.
Believe what you want - once you've implemented the same basic functionality from scratch a few dozen times, it's not all that hard. Really.
In other words, how much of your companys time have you wasted, and for what gain? Especially considering you'll have to pull in libc and libc++ anyway because 3rd party libraries depend on it? Not mentioning the overhead in converting back and forth between string representations?
For cstrings, there's NO overhead, even with multiple strings stuffed in a single alloc(), since you just pass a pointer to the head of the string, and when it hits the first embedded 0x00, it's good as far as strncmp, bsearch, etc are concerned.
Not So Fun Fact: 24 years after Microsoft started the "DOS is Dead" campaign, there are more businesses running DOS apps in a window or full-screen under Windows, or via middleware, than there are business Linux desktops.
That's the sort of "failure to thrive" that really hurts.
When you can't even compete with a long-dead product, you have to ask "what went wrong?" It's not just marketing... the "copyleft" model simply doesn't allow for businesses (or individual developers) to sell software as their core business.
Nobody's going to invest $25 to $100 million to develop a *real*+secure Windows ABI for linux kernels if they can't sell it over and over again to recoup their investment.
The user has to do the locking because the STL is not a magic bullet. You end up having to lock more pessimistically because the underlying implementation may do strange things if you don't. And yes, you have to lock even on reads because otherwise you may mess up in a read/increment/write for any container.
Now extend this to a string. Doing anything that depends on knowing the length of that string (searching, appending, prepending, swapping, reversing, COPYING, etc) needs to be locked. So you end up having to lock on a read because, well, it's the STL and you don't have the same guarantees as if you wrote your own. So rather than lock on just a small section, if using the STL you end up having to go with more coarse-grained locks because otherwise subtle bugs emerge under load.
The STL is not the optimal solution. You can use it, but for a multi-threaded app I won't. It's simply not worth it. That's not to say it's not worth it for YOU. After all, YMMV, you may not be the one stuck fixing something that works fine with 5 or 10 threads but not 500, or whatever.
And STL_LOCK and STL_UNLOCK have been part of stl_lock.h from SGI (the inventors of the STL) since 1998, so they ARE part of the STL by definition. More modern implementations may have replaced them, but the function is still the same - to ensure that only one thread at a time has access to critical parts. And now that we've moved to multiple cores, it's become an even bigger problem since we now have to lock across cores.
By and large the performance of this library should be acceptable for most needs. However, you should note that the library's primary emphasis is on accuracy and numerical stability, and not speed.
... as for...
Why bother writing a vector-class when you have std::vector
... because I can write my own that does ONLY what I want for that particular application, doesn't include any other baggage, and as a consequence is easier to debug. Knowing exactly what's going on "under the hood" is never a bad thing. Why are you defending "dumbing-down"?
The thread-safety of the circular_buffer is the same as the thread-safety of containers in most STL implementations. This means the circular_buffer is not thread-safe. The thread-safety is guarantied only in the sense that simultaneous accesses to distinct instances of the circular_buffer are safe, and simultaneous read accesses to a shared circular_buffer are safe.
If multiple threads access a single circular_buffer, and at least one of the threads may potentially write, then the user is responsible for ensuring mutual exclusion between the threads during the container accesses. The mutual exclusion between the threads can be achieved by wrapping operations of the underlying circular_buffer with a lock acquisition and release. (See the Bounded Buffer Example.)
So managing a collection such as a thread_pool or gather/scatter array requires locking.
Dr. Florian Kaps. Not who you think he is, so stop being such a knee-jerk freetard already. Or go sit in the corner with RMS and the other smelly kooks.
It's definitely less, because a simple string class that only allocates a string buffer, appends to it, frees itself when it goes out of scope, and is guaranteed to always has a proper none-null value (even if it's only 1 byte, and that byte is itself null) is easy to "maintain". There's really no maintenance once it's done.
As for adding functionality - you don't. You either create a separate independent class, or derive from that class, and add functionality. So again, not a big deal. Quick and lean, easy to maintain, and no hassle debugging in a multi-threaded environment.
As for your "why bother"? 400 threads+100threads+400threads (not a contrived example, but from real life, as in - "been there-done that"), each adding both the bloat of the STL and the unnecessary locking/unlocking (and getting rid of the SmartPtr class was also worth it, but that's another story) for a lousy string class is not trivial, not when compared to a couple hundred bytes extra per instance for a simple home-made class, and not compared to performance overhead.
It's funny - I spent something like $80 buying the TR1 hardcover documentation, and having read it 3 times, I *still* think it was $80 that was mostly a waste of money. (Not completely - it at least looks good on the shelf, but that's about it).
But you go ahead and keep using the STL. One person's garbage is another person's treasure, YMMV, it's like vi vs emacs, etc. There are probably valid reasons for going either way, depending on the resources available and the task at hand. If it's something you're only going to run once in a while, and performance isn't critical, use whatever floats your boat.
Removing all those calls to STL_LOCK and STL_UNLOCK was a big win. Re-writing the other containers so as not to use the STL was no big deal. It paid for itself just in compiler time savings, and made debugging so much easier.
The STL provides general-purpose functionality. Why bother when you can just whip out a specific-purpose class?
First, you only have to have ONE person in your org write that custom string class that does exactly what you want, no unpredictable side effects, no bloat.
That 15 minutes pays itself back almost immediately, both in easier debugging (less code to debug) and quicker compile times,
Second, 3rd party libraries are always going to be a problem, but usually you just give them a pointer to (a copy of) the data structure, never to your class. No big deal. I null-terminated string (c-style string) is a null-terminated string. A string with the first n bytes giving the actual size (a pascal-style string, can also be used for BLOBs) is a string with the first n bytes giving the actual size. These are the two standard ways of modeling string data.
why not trade space for time / money? We make all kinds of optimization trade offs already; ease of maintenance tends to not be one we often think of.
... because you can either pay for that optimization ONCE, at coding time, or forever at run-time. And that "forever" gets propagated to any other code that exercises that code, either as a separate routine, or compiled in as part of the program.
It's why we don't have operating systems written in perl.
Plus, someone who can do this sort of thing as a habit is probably going to be producing better code overall anyway.
The 3-ring binder manual alone was a thing of beauty. And new drivers were as simple as editing a text file. Sure, the graphics were limited to 640x200x16 on an RGB monitor, but for its' time, it was miles ahead of both CGA and Hercules. (you *could* get 64 colors to display at once by swapping the palette repeatedly, for example, on each scan line, same as you could display multiple font sizes/colors and sort-of-graphics on a purely DOS text screen by playing with the character generator in real time a la the Clipper Toolkit 3.0).
Then again, there are still people putting out small usable operating systems written in assembler, such as menuetOS that fit on a single floppy.
Why not just recommend he continue to use the ClusterF$ck file system and be done with it?
After all, the OP is using RAID as a backup ("I have suffered twice through complete loss of data once due to accidentally not re-enabling the notification on my hardware RAID and having an array power supply fail and the RAID controller was unable to recover half of the entire array").
Well, part of that problem is that QT is buggy, and poorly designed, compared to the libraries we used "back in the day" when every byte counted, and coders were acutely aware of that.
They should try coding on a minimal system (try "64k is enough") for a few months. There were operating systems that supported multiple users in 64k, and multiple graphical screens in 128k (and would run a dozen copies of flight sim, rogue, etc. in 512k).
Then again, today's programmers would rather import the whole STL just to be able to use one String, rather than take 15 minutes to write their own class. (oops, they couldn't write one in 15 minutes... oh well...)
I think you misunderstood FOSS with rampant consumerism. Show me where the free software definition say "make the life of users easier", and maybe I will start to see you as worthwhile of my time.
I think you already lost that one, since you have already replied:-)
And the devs who have made $2 billion and counting off of Apple's App Store show that F/LOSS copyleft can't compete economically, because anyone can just take your code for the asking.
Programmers have to eat. F/LOSS licensing that requires copyleft doesn't do it for the vast majority of programmers, and is becoming more and more irrelevant.
And humans are just cockroaches with a few mutations specific to humans.
Those "few specific mutations" make a lot of difference, both in appearance, and in basic functions such as how often they come into heat. Wolves, once a year. Dogs... normally twice a year, but they can come into heat pretty much any time. Wolves pair bond, dogs don't. Wolves generally don't do incest... dogs, they're dogs, they'll screw anything, including your leg, given a chance.
Slashdot Mirror
THAT is what would really hurt them. And while it might also slow down the economy for a while, in the long run it would be healthier, as people paid $X for an item, not $X+50% over N years in interest. That interest is money that could be spent locally.
All very well and good, but the point is that it's a lot cheaper (unless you put a value of $0.00 on your time) to just use the "free" windows that comes with your new computer than it is to use Wine, which can't even run simpler games like SimCity2000 (released 1995) without crashing at some point.
For those wondering what RED cameras are, does 4096x2304 pixels and up, at 48fps, make you drool?
Common functionality for string classes includes operator overloading, array-like accesses, copy constructors dealing with other objects, pointers to other objects, pointers to c-strings, midstring, substring, trim, index, rindex, cmp, ==, >=, <=, etc. That's a lot more functionality than the basics I wrote about (and if you later find you need it, you can always add it at that point).
Your post makes it clear that you are being willfully obdurate.
As for build times, remember that if you're using the STL (which was the example given), the compiler has to create the templated object at compile time. That's not just "oh, I only need to link to a library". But by the same token, there's no reason that any custom class I write can't be compiled once, and then just linked to, so what was your point again?
The question remains, if you can't write simple classes, why should anyone trust you with anything more complex? And why should anyone have to put up with code bloat, which was the original topic ...
Straw man argument. If all I need is a string class that can allocate, free, append, copy and replace strings, I don't need a string class that "implements everything common to string classes".
Also, in custom classes, you're guaranteed that ONLY the code you wrote is compiled and linked to, leading to quicker compiles, and also quicker loading (since there's less need for fix-ups at load time, unless you're already writing position-independent code).
The vast majority of cases are like that - you don't need a "kitchen sink" class, and including all that extra code just gives you more areas for bugs to surface.
Most programmers can't even do fizzbin (or bing, bang, boom, or whatever it's called today). When confronted with a problem, their first instinct is to "solve it with google". If you can't even implement a stack, a linked list, a string class, a queue, or any other basic structure, why should anyone trust you to be able to implement anything harder? These are basic skills for any c/c++ programmer. If you can't implement them, you're really not qualified for the job.
That people seem to think these are "hard" is rather mind-boggling. That it's somehow "wrong" to write the perfect solution for the current problem. 10% here, 5% there, 3% in another place, it eventually adds up. And in some cases, it's several orders of magnitude difference. Example: I implemented the same video routines in both c and assembler. The assembler routine was 200 times faster. Another example - disk reads using c and assembler - the assembler routine was over 50% faster than the drives' rated speed - and a lot smaller. Please don't knock it if you haven't really tried it, because there may come a day when you really need that extra margin that writing your own class provides.
Just because you can't justify it doesn't mean that there are no cases where it's justified.
Many voted for Obama as a protest against the bailouts. "Main Street, not Wall Street." That was a couple of years ago. That Obama has been a disappointment in this respect is an understatement.
Or have you failed to notice OWS?
Oh how naive they are when they're young :-p
When you've been re-implementing the same basic classes for a couple of decades (custom strings, stacks, queues, linked lists, etc), doing it one more time, again customized to your current needs, is really no big deal.
It's not like you need to provide a whole slew of generic methods "just in case" and debug them.
Also, we're not talking c here, but c++ (implementing classes in c is also easily doable, but you have to remember to pass an explicit pointer to this as your first parameter, and manually call any parent classes rather than have the compiler do it for you to implement inheritance).
If people can't implement (or are afraid to implement) the basic classes that are everywhere, how much can you trust any class they DO implement?
Or for under $230, buy a 14mp camera with 22x optical zoom, 4x digital, 16 gig storage, wifi picture transfer, 720p video, 3" LCD viewer, usb, hdmi, batteries, cables and camera bag all included.
Or for $140, settle for 16mp/15x optical zoom, 2.7" display, and only vga movies.
Heck, you can get a really nice 14mp Nikon DSLR with an 18-55mm lens, 1920x1080x24p video, RAW, various memory cards, 3" screen, 1/4000 to 30 seconds exposure, all the usual bells and whistles like auto focus, auto follow, internal dust-off, - just marked down another $100 to $550.00, and if you don't like the lens, you can swap it.
At $3 per color picture for the sx-70 film, it would take less than 200 pictures to make the Nikon free - and you can make unlimited copies w/o degradation.
Yes, the SX-70 was a real innovation for its time ... but there's a host of reasons it's dead.
Fun times the first time it actually worked!
No, because not all accesses require that the container be locked, whereas some accesses require that locking be done at a higher level to avoid deadlocks.
Also, I definitely do not believe in SmartPtrs, because they can always be eliminated by looking more closely at the problem. And lets face it - if you're coding in c, you have to go my way anyway, since the STL isn't even available (though you can still create your own "classes" - you just have to pass this explicitly as the first parameter, and you have to explicitly call any parents you want to inherit any functionality from - not a big deal).
I described the most naive implementation possible, for simplicity. In reality, you normally alloc() a decent-sized chunk, and only realloc() as needed to grow. You can also use that technique to stuff multiple strings inside one chunk. This is an old technique, used by (eg) Borland back in 1995.
Believe what you want - once you've implemented the same basic functionality from scratch a few dozen times, it's not all that hard. Really.
For cstrings, there's NO overhead, even with multiple strings stuffed in a single alloc(), since you just pass a pointer to the head of the string, and when it hits the first embedded 0x00, it's good as far as strncmp, bsearch, etc are concerned.
Not So Fun Fact: 24 years after Microsoft started the "DOS is Dead" campaign, there are more businesses running DOS apps in a window or full-screen under Windows, or via middleware, than there are business Linux desktops.
That's the sort of "failure to thrive" that really hurts.
When you can't even compete with a long-dead product, you have to ask "what went wrong?" It's not just marketing ... the "copyleft" model simply doesn't allow for businesses (or individual developers) to sell software as their core business.
Nobody's going to invest $25 to $100 million to develop a *real*+secure Windows ABI for linux kernels if they can't sell it over and over again to recoup their investment.
Now extend this to a string. Doing anything that depends on knowing the length of that string (searching, appending, prepending, swapping, reversing, COPYING, etc) needs to be locked. So you end up having to lock on a read because, well, it's the STL and you don't have the same guarantees as if you wrote your own. So rather than lock on just a small section, if using the STL you end up having to go with more coarse-grained locks because otherwise subtle bugs emerge under load.
The STL is not the optimal solution. You can use it, but for a multi-threaded app I won't. It's simply not worth it. That's not to say it's not worth it for YOU. After all, YMMV, you may not be the one stuck fixing something that works fine with 5 or 10 threads but not 500, or whatever.
And STL_LOCK and STL_UNLOCK have been part of stl_lock.h from SGI (the inventors of the STL) since 1998, so they ARE part of the STL by definition. More modern implementations may have replaced them, but the function is still the same - to ensure that only one thread at a time has access to critical parts. And now that we've moved to multiple cores, it's become an even bigger problem since we now have to lock across cores.
Go tell that to to the originators of the STL, SGI. They would disagree.
The boost STL documentation makes the point that it is NOT aimed for high performance
http://www.boost.org/doc/libs/1_43_0/libs/math/doc/sf_and_dist/html/math_toolkit/main_overview/perf_over.html
So managing a collection such as a thread_pool or gather/scatter array requires locking.
Can't you even read the SUMMARY?
Dr. Florian Kaps. Not who you think he is, so stop being such a knee-jerk freetard already. Or go sit in the corner with RMS and the other smelly kooks.
As for adding functionality - you don't. You either create a separate independent class, or derive from that class, and add functionality. So again, not a big deal. Quick and lean, easy to maintain, and no hassle debugging in a multi-threaded environment.
As for your "why bother"? 400 threads+100threads+400threads (not a contrived example, but from real life, as in - "been there-done that"), each adding both the bloat of the STL and the unnecessary locking/unlocking (and getting rid of the SmartPtr class was also worth it, but that's another story) for a lousy string class is not trivial, not when compared to a couple hundred bytes extra per instance for a simple home-made class, and not compared to performance overhead.
It's funny - I spent something like $80 buying the TR1 hardcover documentation, and having read it 3 times, I *still* think it was $80 that was mostly a waste of money. (Not completely - it at least looks good on the shelf, but that's about it).
But you go ahead and keep using the STL. One person's garbage is another person's treasure, YMMV, it's like vi vs emacs, etc. There are probably valid reasons for going either way, depending on the resources available and the task at hand. If it's something you're only going to run once in a while, and performance isn't critical, use whatever floats your boat.
Try using the STL with threads. It's fugly.
Removing all those calls to STL_LOCK and STL_UNLOCK was a big win. Re-writing the other containers so as not to use the STL was no big deal. It paid for itself just in compiler time savings, and made debugging so much easier.
The STL provides general-purpose functionality. Why bother when you can just whip out a specific-purpose class?
First, you only have to have ONE person in your org write that custom string class that does exactly what you want, no unpredictable side effects, no bloat.
That 15 minutes pays itself back almost immediately, both in easier debugging (less code to debug) and quicker compile times,
Second, 3rd party libraries are always going to be a problem, but usually you just give them a pointer to (a copy of) the data structure, never to your class. No big deal. I null-terminated string (c-style string) is a null-terminated string. A string with the first n bytes giving the actual size (a pascal-style string, can also be used for BLOBs) is a string with the first n bytes giving the actual size. These are the two standard ways of modeling string data.
It's why we don't have operating systems written in perl.
Plus, someone who can do this sort of thing as a habit is probably going to be producing better code overall anyway.
The 3-ring binder manual alone was a thing of beauty. And new drivers were as simple as editing a text file. Sure, the graphics were limited to 640x200x16 on an RGB monitor, but for its' time, it was miles ahead of both CGA and Hercules. (you *could* get 64 colors to display at once by swapping the palette repeatedly, for example, on each scan line, same as you could display multiple font sizes/colors and sort-of-graphics on a purely DOS text screen by playing with the character generator in real time a la the Clipper Toolkit 3.0).
Then again, there are still people putting out small usable operating systems written in assembler, such as menuetOS that fit on a single floppy.
Why not just recommend he continue to use the ClusterF$ck file system and be done with it?
After all, the OP is using RAID as a backup ("I have suffered twice through complete loss of data once due to accidentally not re-enabling the notification on my hardware RAID and having an array power supply fail and the RAID controller was unable to recover half of the entire array").
Well, part of that problem is that QT is buggy, and poorly designed, compared to the libraries we used "back in the day" when every byte counted, and coders were acutely aware of that.
They should try coding on a minimal system (try "64k is enough") for a few months. There were operating systems that supported multiple users in 64k, and multiple graphical screens in 128k (and would run a dozen copies of flight sim, rogue, etc. in 512k).
Then again, today's programmers would rather import the whole STL just to be able to use one String, rather than take 15 minutes to write their own class. (oops, they couldn't write one in 15 minutes ... oh well ...)
I think you already lost that one, since you have already replied :-)
And the devs who have made $2 billion and counting off of Apple's App Store show that F/LOSS copyleft can't compete economically, because anyone can just take your code for the asking.
Programmers have to eat. F/LOSS licensing that requires copyleft doesn't do it for the vast majority of programmers, and is becoming more and more irrelevant.
And humans are just cockroaches with a few mutations specific to humans.
Those "few specific mutations" make a lot of difference, both in appearance, and in basic functions such as how often they come into heat. Wolves, once a year. Dogs ... normally twice a year, but they can come into heat pretty much any time. Wolves pair bond, dogs don't. Wolves generally don't do incest ... dogs, they're dogs, they'll screw anything, including your leg, given a chance.
You can park it next to RMS and his tour rider ...