I had the pleasure of access to and use of an Amiga 1000 in '86. It hosted many of my firsts in computing:
First use of a graphical interface
First use of virtualization (hosted an IBM DOS virtual environment in a window - used for running and building DOS applications for IBM PC - the Amiga OS was perfect for this - since it virtualized it's own components as well)
First filled polygon video game (3D up to that point was wireframe)
First real multimedia PC used
First use of a PC with a multitasking operating system
First use of full featured embedded scripting capabilities in an operating system (MS DOS batch processing doesn't count)
After using the Amiga, nothing that followed really surprised me - but most commercial solutions I found limiting in one way or another (e.g. Windows 3.1 lack of preemptive multitasking).
In '95 was looking at OS2 Warp as a better alternative to Windows '95 [I wanted something that had tools I could quickly be productive with; I spent many hours with the Win32 API bible with little to show for it - and J++ just was a fail from an interoperability standpoint] - when I was introduced to Linux - which had what was missing, and dovetailed nicely with my studies at the university - (the computer science lab was well equipped with Sun Solaris machines - and we did all of our development coursework on Unix as a result - and when I got Slackware 2.3 up and running - I started dialing in my projects from home - my first exposure to telecommuting).
The biggest lesson I took from my experience with the Amiga is that being productive with a computer should be easy - and if it isn't then you should look somewhere else until you find it. It may seem counterintuitive given that I ended up with one of the most difficult distros to install at the time. Having a built-in tool set in the form of command line scripting, and other extension languages, in addition to the core system programming languages was key to my own efficiency in getting things done. That being said - today, even for someone who knows how to program, finding easier/quicker ways to get work done is valuable. Everyone is not a computer scientist - and shouldn't have to be to make working tools for themselves easily. While projects have addressed subsets in this arena (spreadsheets, wordprocessing etc), no one has address the fundamental problem of creating a malleable tool for general purpose use - that I am aware of.
IT departments in large companies, and the shrink-wrapped software companies do a good job of accomplishing large projects and particular popular niches (standard office suites) - but they are horrible when addressing the unique needs of the individual. That's where something like hypercard would find a home.
The only good thing I can see about systemd is the exposure of some Linux system APIs that were not exposed via the POSIX subsystem. Nice - but not required by most of us - and could be added to existing standards based initialization daemons without totally rewriting the rules.
Otherwise it seems to be more likely a thinly veiled (actually not veiled at all...given comments of the principles) attempt to fragment the POSIX world - and forcing projects with limited resources to make a Hobson's choice of whether to support systemd based Linux or POSIX standards exclusively. It breaks write once - compile/run anywhere - that was generally available for those who made sure their applications were POSIX compliant. This means that a lot of software that was available across Linux, and Unix flavors (BSD) will now be exclusively available on one or the other - thus fragmenting the *nix world.
Software is not separate from the ethics that surrounds it. This approach and apparent rabid anti-interoperability view is arrogant and self-serving at the expense of cooperation and choice. Furthermore, the monolithic architecture, obfuscated binary logs, and centralized configuration are antithetical to the Unix way - and makes a linux system as difficult to deal with as a Windows system from an automation and management perspective, and raises concerns in terms of security (the greater the complexity in a system, the greater the opportunity for bugs - and thus the greater the attack surface).
Finally it throws away many many years of experience/knowledge acquired by system admins, developers, and users about how a *nix system operates and is configured. This fragmentation of the human factors aspect will by its very nature cause faults/issues during operation.
So - for a host of reasons, I believe it is technically - and more importantly - ethically wrong.
There is actually one more good thing I can think of: it will spawn new distros, software projects to provide alternatives of various applications in the stack, and perhaps new operating systems altogether - with a renewed focus on design simplicity (KISS) and all of the benefits that come from that. Once a system becomes too complex to understand - are you sure you can trust it?
So to recap: systemd has two things going for it; exposure of Linux APIs, and the power to breath life into the further exploration of alternatives in the OS/application layer.
In a few years the miniaturization of components is going to make this difficult if not impossible to enforce.
If you can't distinguish a regular pair of glasses from these devices...
But, why can't I just rip out systemd? Oh - because so many service projects/distros are only supporting systemd today that you have to have it around if anything you download in the distro happens to use the API of the non-POSIX POS that is systemd.
systemd core files are not written to disk as files - they are written to the binary log file - you have to extract the data first to run debug.
systemd log files are binary; you can't run grep or other text parsing tools against it for automation - unless you extract the data first.
systemd encourages abandonment of POSIX compliance - which is a key component of the interoperability between various flavors of Unix and Linux (I loved being able to write a shell script on a Unix machine, and copy it over to a Linux machine with little to no modification). Dennis Ritchie must be spinning in his grave right now at this bastardization of his brain child.
The only way to avoid this is to roll your own distro - or support distros that stay clear of it (I was shocked to hear even Slackware was considering support for systemd - given that it has always been as close to SystemV Unix-like that you could get in the Linux world. Thankfully - so far they have not succumbed.)
For people who run desktop machines for their own use - running applications in user space for the most part - systemd may be fine. For those of us running servers, with many man hours of system administrative automation in place - this spells catastrophe in the form of forced obsolescence of our custom code and automation.
As I read in one article - if systemd is allowed to prevail, then we can all kiss the days of an administrator controlling his system his own way goodbye. It will split the work of people who do development - and at some point they will not be able to continue; one case in point: http://alien.slackbook.org/blog/on-lkml-an-open-letter-to-the-linux-world/
From that article:
Last week I asked the SDDM developers to reconsider their decision no longer to support ConsoleKit because Slackware does not have systemd or logind and thus we need to keep using ConsoleKit. The answer could be expected: “answer is no because ConsoleKit is deprecated and is not maintained anymore” and therefore I had to patch it in myself.
Of course, the ConsoleKit successor systemd-logind, written by the same team that gave us all the *Kit crap, depends on PAM which we also do not have in Slackware. One of the fellow core developers in Slackware, who is intimately familiar with the KDE developers community, has heard from multiple sources that KDE is moving towards a hard dependency on systemd (probably because they are going to need the functionality of systemd-logind). We all know what that means, folks! It will be the day that I must stop delivering you new KDE package releases for Slackware. That’ll be the day.
So this turn of events might be nice for some script kiddie sitting in his mother's basement....but for the rest of us who have to get work done with and through Linux - this is a royal pain in the arse.
While you say you aren't going to wield your patents offensively, we can't be absolutely sure you won't.
It really comes down to an ethical choice to avoid them altogether, and fight them vigorously when they do come knocking on your doorstep, or to embrace them in the sake of 'defense'.
Power corrupts - and so does the power acrued from misapplied patents.
I don't disagree with your overall premise: bureaucratic 'big design up front' methods don't work except for an exceedingly small subset of problems in the real world.
However, you largely ignore a key point that I think the IEEE is (belatedly) trying to address: our focus from a design perspective to this point has been first meeting the functional design criteria, and lastly security (if you have time to deal with that at all - which in my experience ends up being the first thing that gets cut when time is at a premium and pressure mounts to ship).
Security has to be seen as a core function of every application that plans on communicating across a network, and also for many that don't by necessity, due to their incestuous relationship to other systems running on a machine that do. I also think that if you start your overall design with security in mind - that will influence various factors of the design - from API construction, to modularity, to the design of the tools, and operating systems the resultant applications live on/in.
To do that well without any framework or controls would require every application programmer to be a top notch systems developer. In my experience the vast majority of professionals in the application development space will never rise to that level of expertise. But code must be written - and applications deployed as the appetite for more and more automation does not abate. There are not enough programmers competent in systems development to do the job without any help. So, what do we do?
I have a pretty good idea about what I think should happen - but I'm curious, what you would do given that reality (assuming you can't guarantee deep competency)?
This brings to mind the purposes of creating and using code in the first place:
Where you are the only person that needs to see and understand it - this is fine; it serves your purposes happily for you.
On the other hand, where the purpose of creating and using the code extends beyond one person, this structure does not serve that need effectively. This is primarily because, while it may function, it is too brittle to be maintained by a team of developers over many years through many iterations in design without considerable time and errors generated in the process.
From seeing things like this, I would argue that there are way too many clever programmers - and not enough smart ones.
Your assumption there is that the youngsters turn out new ideas exclusively. The best ideas I have seen came from people who were over 40; youth does not infer a monopoly on ideas.
How much money did you spend in the 1980s on video games? I recall thinking $10 to $20 a day was a lot of money at the arcade back then - but nowhere near enough game time to build up 'pro gamer' skills... were you independently wealthy, or had some other secret?
Bravo! We need more people in this field with your attitude.
Hell, we need more people in general with your attitude - that would solve most of the stupidity I see on a daily basis.
"The lack of a standard library however makes things just repetitious and error prone", doesn't follow. Why would you copy the same code over and over in your application? Are you 'copy-paste' programming? That isn't very smart. Even as minimalistic as C is - it still has subroutines - you could even put them in a separate file from your main application to be reused in more than one program. Code reuse isn't a magical property of OO languages exclusively. Your statement actually illustrates the point - people don't have a fundamental understanding that carries over into all other languages as your abstraction level increases. You don't run before you walk - but in teaching computer science and programming we seem to be trying to do just that with our students today - and the failure of this approach is starting to be obvious in the real world where the rubber meets the road - at least for those of us who have to waste time and resources fixing the results.
C has been described as a wrapper for assembly language, and as such it requires that you really understand how the computer processor works to do anything non-trivial. C++ allows you to do that as well, but C really enforces it - and makes you think about building your own libraries of routines to do the higher order abstractions yourself.
This is valuable because most higher abstraction entry level languages today don't give you that experience (e.g. Java) - which really is what is important when designing good software, or conversely trying to troubleshoot someone else's bad software.
Case in point: We had a java application written by a vendor. It ran slow, but worse than that, it would crash after being up for some time. To make a long story short, the vendor had short circuited Java's garbage collection mechanism. All the objects it was creating in memory where not being released because they were not going out of scope. Java would reach its configured memory high water mark, and shutdown.
When we showed this to the Java programmer - he didn't have a clue as to why this happened to his application. So I would have to agree with Joel that Java is not a hard enough language because it abstracts away too much of the underlying machine. If that is all a programmer knows, then he is not a complete programmer IMHO. So I would have to say here is some support for his unsupportable premise.
Ned Lud, is that you? The 17th century is calling and they want their mime back.
Seriously though, this 'techno-shit' is what is powering the next revolution - allowing us to be far more efficient than we have been in the past. In a world of dwindling oil supplies, climate change, and over population, technology is what will allow us to survive this world, and migrate to the next. I don't know about you, but I'm not interested in contemplating future generations groveling in the dust of this parched world as it spins down to nothing. Doing my best now to move the technology bar - even a little bit in the right direction is worth the effort taken in that light.
I'm curious as to your occupation - given the subject matter of/.
I tend to agree with sticking with Moleskin(sic) - preferably 8 1/2 X 11 size --- nonruled (blank). I've tried electronic logs - I've tried electronic drawing apps (e.g. Papyrus on a Nexus 7 Android system). The main problem for me is not only do I want to write in it - but I find freeform drawing to be more helpful in conjunction with the writing. The Nexus pixel sizes for drawing where too coarse - and while you can zoom in and out -- the drawings always ended up looking odd - and took longer than just writing on paper. The only other acceptable solution I found was a $1500 Wacom electronic drawing tablet --- so I continue to buy Moleskin at a fraction of the cost.
So that does bring up the problem that is mentioned regarding indexing - and here is how I deal with that:
Each entry is dated in this manner: yyyymmdd e.g. 20140421 ; in this way each volume contains a series of entries that are uniquely numbered; if you need to add more than one entry per day - then just add hours and minutes as needed: 20140421:1405 (using the colon to visually separate the date from the time is preferred by me).
I also encode each entry as to 'type', where types are based upon single letter codes: C = computer science, A = art, etc... I put the letter code inside of a square in the upper - outer corner of each page where an entry begins.
The next step is to create an electronic index to key entries in your logs --- assuming you number your volumes sequentially - you can identify an entry like this:
Vol 2, 20140421:1400 History of FOO
With this system you can have both the flexibility of combining freehand drawing with your log entries, and also keep an index of your key entries organized however you like (perhaps by type, or project codes etc...you can expand this as you need beyond my simple method).
Apocalypse in current usage means the end of the world. By that definition - no skill will be 'Apocalypse Useful' - because no one will be around in the aftermath of the end of time (with the possible exception of an intrepid band of our great grandchildren who might figure out how to jump between multiple universe branes at the precise moment of the 'big rip' - a very remote possibility imho).
Really what we are talking about are events that while devastating, are short of the level of destruction needed to end the world. The very nature of that definition means that there will be locations that are not directly impacted by whatever happened. The most key struggle would come from dependency on things that moved by long distance transport; various foods, fuels, technology, and other manufactured goods. As a result, local replacements would have to be found and developed.
In those areas harder hit - it would be very bad, if not impossible to survive after the initial event. I can see migrations of people from these 'hot zones' to more habitable areas. Refugees might put too much pressure on less impacted areas - causing a crisis in those areas. The first few years after the event might be very chaotic due to these population pressures and migrations. The very best way to avoid a humanitarian disaster would be to make sure all of the surviving zones have good communications - and plans in place for relocating and organizing the influx of survivors into their communities. I think you would also want to move as quickly as possible to restore technology to society - maybe not in the exact forms that we are used to - but restoration just the same. Having running water, food, medicines, heating and cooling, and energy in general are critical to sustaining life. As a result, I think all disciplines will be useful to society in that situation in one way or another. One example: artists and story tellers would be useful in bringing entertainment and beauty into the lives of the survivor communities - and might be very important in keeping human knowledge alive until information systems can once again be restored. Ultimately, people would be so hard pressed to survive that it would quickly become apparent that the survivors will do better by banding together rather than fighting among themselves.
Overall - I think if the event was large enough to depopulate the world significantly, I think the survivors would be very busy indeed, with little time or energy to waste of the staples of post-apocalyptic fiction: warlords, societal breakdown, and descent of our humanity to that of the animals, leading us to prey upon our fellow man. While there may be a few sociopaths who try to benefit from the situation, I expect the rest of us to quickly control that. Essentially, humanity has lived through these sorts of things in the past, and I am sure we would make do and get on with living in the aftermath of whatever mother nature sends our way again.
My very first program was 'hello world' in Basic on the High School computer lab's Apple ][ in 1981 (learned Fortran in that same course). I got a TI 99A for my birthday that year, and I wrote more noddy programs in Basic over the next few years, saving them meticulously on cassette tape.
I can't imagine using Basic for anything useful these days, but it was fun while it lasted.
Another aspect of the problem - Corporate policy in most large companies is to treat all of your IT programmers as identical widgets. This policy stems from HR, Finance, and IT efforts to 'normalize' positions so they can be circumscribed enough to allow 'efficient' allocation of resources, or more damaging, the allocation of resources that can be outsourced wholesale. Ultimately it all comes down to cost reduction. Poor results of IT, coupled with IT being strictly a cost center - leads to this outcome (the cost vs. value proposition as seen through the eyes of the heads of the business).
This of course, drags down everyone with it causing many good people to leave or get caught in the outsourcing net. If they are lucky - they do manage to move up into management (architects etc) - and hopefully they can influence the designs - but again - what is left behind is tragically impossible of effiently implementing even the best designs - so the problem feeds itself as your best get pulled away from programming.
Slashdot Mirror
I had the pleasure of access to and use of an Amiga 1000 in '86. It hosted many of my firsts in computing:
After using the Amiga, nothing that followed really surprised me - but most commercial solutions I found limiting in one way or another (e.g. Windows 3.1 lack of preemptive multitasking).
In '95 was looking at OS2 Warp as a better alternative to Windows '95 [I wanted something that had tools I could quickly be productive with; I spent many hours with the Win32 API bible with little to show for it - and J++ just was a fail from an interoperability standpoint] - when I was introduced to Linux - which had what was missing, and dovetailed nicely with my studies at the university - (the computer science lab was well equipped with Sun Solaris machines - and we did all of our development coursework on Unix as a result - and when I got Slackware 2.3 up and running - I started dialing in my projects from home - my first exposure to telecommuting).
The biggest lesson I took from my experience with the Amiga is that being productive with a computer should be easy - and if it isn't then you should look somewhere else until you find it. It may seem counterintuitive given that I ended up with one of the most difficult distros to install at the time. Having a built-in tool set in the form of command line scripting, and other extension languages, in addition to the core system programming languages was key to my own efficiency in getting things done. That being said - today, even for someone who knows how to program, finding easier/quicker ways to get work done is valuable. Everyone is not a computer scientist - and shouldn't have to be to make working tools for themselves easily. While projects have addressed subsets in this arena (spreadsheets, wordprocessing etc), no one has address the fundamental problem of creating a malleable tool for general purpose use - that I am aware of.
IT departments in large companies, and the shrink-wrapped software companies do a good job of accomplishing large projects and particular popular niches (standard office suites) - but they are horrible when addressing the unique needs of the individual. That's where something like hypercard would find a home.
The only good thing I can see about systemd is the exposure of some Linux system APIs that were not exposed via the POSIX subsystem. Nice - but not required by most of us - and could be added to existing standards based initialization daemons without totally rewriting the rules.
Otherwise it seems to be more likely a thinly veiled (actually not veiled at all...given comments of the principles) attempt to fragment the POSIX world - and forcing projects with limited resources to make a Hobson's choice of whether to support systemd based Linux or POSIX standards exclusively. It breaks write once - compile/run anywhere - that was generally available for those who made sure their applications were POSIX compliant. This means that a lot of software that was available across Linux, and Unix flavors (BSD) will now be exclusively available on one or the other - thus fragmenting the *nix world.
Software is not separate from the ethics that surrounds it. This approach and apparent rabid anti-interoperability view is arrogant and self-serving at the expense of cooperation and choice. Furthermore, the monolithic architecture, obfuscated binary logs, and centralized configuration are antithetical to the Unix way - and makes a linux system as difficult to deal with as a Windows system from an automation and management perspective, and raises concerns in terms of security (the greater the complexity in a system, the greater the opportunity for bugs - and thus the greater the attack surface).
Finally it throws away many many years of experience/knowledge acquired by system admins, developers, and users about how a *nix system operates and is configured. This fragmentation of the human factors aspect will by its very nature cause faults/issues during operation.
So - for a host of reasons, I believe it is technically - and more importantly - ethically wrong.
There is actually one more good thing I can think of: it will spawn new distros, software projects to provide alternatives of various applications in the stack, and perhaps new operating systems altogether - with a renewed focus on design simplicity (KISS) and all of the benefits that come from that. Once a system becomes too complex to understand - are you sure you can trust it? So to recap: systemd has two things going for it; exposure of Linux APIs, and the power to breath life into the further exploration of alternatives in the OS/application layer.
In a few years the miniaturization of components is going to make this difficult if not impossible to enforce. If you can't distinguish a regular pair of glasses from these devices...
Don't forget to uninstall Pottering. PulseAudio was just the beginning.
Is there a compile switch for that, or do I need to write a script? UninstallPoettering.sh
But, why can't I just rip out systemd? Oh - because so many service projects/distros are only supporting systemd today that you have to have it around if anything you download in the distro happens to use the API of the non-POSIX POS that is systemd.
systemd core files are not written to disk as files - they are written to the binary log file - you have to extract the data first to run debug.
systemd log files are binary; you can't run grep or other text parsing tools against it for automation - unless you extract the data first.
systemd encourages abandonment of POSIX compliance - which is a key component of the interoperability between various flavors of Unix and Linux (I loved being able to write a shell script on a Unix machine, and copy it over to a Linux machine with little to no modification). Dennis Ritchie must be spinning in his grave right now at this bastardization of his brain child.
The only way to avoid this is to roll your own distro - or support distros that stay clear of it (I was shocked to hear even Slackware was considering support for systemd - given that it has always been as close to SystemV Unix-like that you could get in the Linux world. Thankfully - so far they have not succumbed.)
For people who run desktop machines for their own use - running applications in user space for the most part - systemd may be fine. For those of us running servers, with many man hours of system administrative automation in place - this spells catastrophe in the form of forced obsolescence of our custom code and automation.
As I read in one article - if systemd is allowed to prevail, then we can all kiss the days of an administrator controlling his system his own way goodbye. It will split the work of people who do development - and at some point they will not be able to continue; one case in point: http://alien.slackbook.org/blog/on-lkml-an-open-letter-to-the-linux-world/
From that article:
So this turn of events might be nice for some script kiddie sitting in his mother's basement....but for the rest of us who have to get work done with and through Linux - this is a royal pain in the arse.
While you say you aren't going to wield your patents offensively, we can't be absolutely sure you won't. It really comes down to an ethical choice to avoid them altogether, and fight them vigorously when they do come knocking on your doorstep, or to embrace them in the sake of 'defense'.
Power corrupts - and so does the power acrued from misapplied patents.
/AGREED/ If you are patenting software you are wrong.
I suppose people like this think Kernagan and Richie(sic) should be collecting royalties on every C application written since the dawn of time?
IBM also made an ergonomic buckling spring keyboard: the model M15 -
http://www.clickykeyboards.com/index.cfm/fa/items.main/parentcat/12675/subcatid/0/id/125888
Why won't anyone make a copy of that? (nudge-nudge Unicomp!)
I don't disagree with your overall premise: bureaucratic 'big design up front' methods don't work except for an exceedingly small subset of problems in the real world.
However, you largely ignore a key point that I think the IEEE is (belatedly) trying to address: our focus from a design perspective to this point has been first meeting the functional design criteria, and lastly security (if you have time to deal with that at all - which in my experience ends up being the first thing that gets cut when time is at a premium and pressure mounts to ship).
Security has to be seen as a core function of every application that plans on communicating across a network, and also for many that don't by necessity, due to their incestuous relationship to other systems running on a machine that do. I also think that if you start your overall design with security in mind - that will influence various factors of the design - from API construction, to modularity, to the design of the tools, and operating systems the resultant applications live on/in.
To do that well without any framework or controls would require every application programmer to be a top notch systems developer. In my experience the vast majority of professionals in the application development space will never rise to that level of expertise. But code must be written - and applications deployed as the appetite for more and more automation does not abate. There are not enough programmers competent in systems development to do the job without any help. So, what do we do?
I have a pretty good idea about what I think should happen - but I'm curious, what you would do given that reality (assuming you can't guarantee deep competency)?
This brings to mind the purposes of creating and using code in the first place:
From seeing things like this, I would argue that there are way too many clever programmers - and not enough smart ones.
Your assumption there is that the youngsters turn out new ideas exclusively. The best ideas I have seen came from people who were over 40; youth does not infer a monopoly on ideas.
How much money did you spend in the 1980s on video games? I recall thinking $10 to $20 a day was a lot of money at the arcade back then - but nowhere near enough game time to build up 'pro gamer' skills... were you independently wealthy, or had some other secret?
Seriously, this is a clear indication to me that this thing probably had all the halmarks of bad projects:
Managing that brittle monstrosity is going to be painful over the long haul. I feel for whoever gets that job.
The questions for those of us in the business: Why do we continue the cycle of poor craftsmanship/performance? What can we do about it?
Anything is possible. The real question: is it probable?
Actually, I would argue that 99% of the functionality is contained in the 263 lines of Python code. All the rest is presentation...
Bravo! We need more people in this field with your attitude. Hell, we need more people in general with your attitude - that would solve most of the stupidity I see on a daily basis.
"The lack of a standard library however makes things just repetitious and error prone", doesn't follow. Why would you copy the same code over and over in your application? Are you 'copy-paste' programming? That isn't very smart. Even as minimalistic as C is - it still has subroutines - you could even put them in a separate file from your main application to be reused in more than one program. Code reuse isn't a magical property of OO languages exclusively. Your statement actually illustrates the point - people don't have a fundamental understanding that carries over into all other languages as your abstraction level increases. You don't run before you walk - but in teaching computer science and programming we seem to be trying to do just that with our students today - and the failure of this approach is starting to be obvious in the real world where the rubber meets the road - at least for those of us who have to waste time and resources fixing the results.
When I start using Python.
C has been described as a wrapper for assembly language, and as such it requires that you really understand how the computer processor works to do anything non-trivial. C++ allows you to do that as well, but C really enforces it - and makes you think about building your own libraries of routines to do the higher order abstractions yourself.
This is valuable because most higher abstraction entry level languages today don't give you that experience (e.g. Java) - which really is what is important when designing good software, or conversely trying to troubleshoot someone else's bad software.
Case in point: We had a java application written by a vendor. It ran slow, but worse than that, it would crash after being up for some time. To make a long story short, the vendor had short circuited Java's garbage collection mechanism. All the objects it was creating in memory where not being released because they were not going out of scope. Java would reach its configured memory high water mark, and shutdown.
When we showed this to the Java programmer - he didn't have a clue as to why this happened to his application. So I would have to agree with Joel that Java is not a hard enough language because it abstracts away too much of the underlying machine. If that is all a programmer knows, then he is not a complete programmer IMHO. So I would have to say here is some support for his unsupportable premise.
Ned Lud, is that you? The 17th century is calling and they want their mime back.
Seriously though, this 'techno-shit' is what is powering the next revolution - allowing us to be far more efficient than we have been in the past. In a world of dwindling oil supplies, climate change, and over population, technology is what will allow us to survive this world, and migrate to the next. I don't know about you, but I'm not interested in contemplating future generations groveling in the dust of this parched world as it spins down to nothing. Doing my best now to move the technology bar - even a little bit in the right direction is worth the effort taken in that light.
I'm curious as to your occupation - given the subject matter of /.
I tend to agree with sticking with Moleskin(sic) - preferably 8 1/2 X 11 size --- nonruled (blank). I've tried electronic logs - I've tried electronic drawing apps (e.g. Papyrus on a Nexus 7 Android system). The main problem for me is not only do I want to write in it - but I find freeform drawing to be more helpful in conjunction with the writing. The Nexus pixel sizes for drawing where too coarse - and while you can zoom in and out -- the drawings always ended up looking odd - and took longer than just writing on paper. The only other acceptable solution I found was a $1500 Wacom electronic drawing tablet --- so I continue to buy Moleskin at a fraction of the cost.
So that does bring up the problem that is mentioned regarding indexing - and here is how I deal with that:
Each entry is dated in this manner: yyyymmdd e.g. 20140421 ; in this way each volume contains a series of entries that are uniquely numbered; if you need to add more than one entry per day - then just add hours and minutes as needed: 20140421:1405 (using the colon to visually separate the date from the time is preferred by me).
I also encode each entry as to 'type', where types are based upon single letter codes: C = computer science, A = art, etc... I put the letter code inside of a square in the upper - outer corner of each page where an entry begins.
The next step is to create an electronic index to key entries in your logs --- assuming you number your volumes sequentially - you can identify an entry like this:
With this system you can have both the flexibility of combining freehand drawing with your log entries, and also keep an index of your key entries organized however you like (perhaps by type, or project codes etc...you can expand this as you need beyond my simple method).
Apocalypse in current usage means the end of the world. By that definition - no skill will be 'Apocalypse Useful' - because no one will be around in the aftermath of the end of time (with the possible exception of an intrepid band of our great grandchildren who might figure out how to jump between multiple universe branes at the precise moment of the 'big rip' - a very remote possibility imho).
Really what we are talking about are events that while devastating, are short of the level of destruction needed to end the world. The very nature of that definition means that there will be locations that are not directly impacted by whatever happened. The most key struggle would come from dependency on things that moved by long distance transport; various foods, fuels, technology, and other manufactured goods. As a result, local replacements would have to be found and developed.
In those areas harder hit - it would be very bad, if not impossible to survive after the initial event. I can see migrations of people from these 'hot zones' to more habitable areas. Refugees might put too much pressure on less impacted areas - causing a crisis in those areas. The first few years after the event might be very chaotic due to these population pressures and migrations. The very best way to avoid a humanitarian disaster would be to make sure all of the surviving zones have good communications - and plans in place for relocating and organizing the influx of survivors into their communities. I think you would also want to move as quickly as possible to restore technology to society - maybe not in the exact forms that we are used to - but restoration just the same. Having running water, food, medicines, heating and cooling, and energy in general are critical to sustaining life. As a result, I think all disciplines will be useful to society in that situation in one way or another. One example: artists and story tellers would be useful in bringing entertainment and beauty into the lives of the survivor communities - and might be very important in keeping human knowledge alive until information systems can once again be restored. Ultimately, people would be so hard pressed to survive that it would quickly become apparent that the survivors will do better by banding together rather than fighting among themselves.
Overall - I think if the event was large enough to depopulate the world significantly, I think the survivors would be very busy indeed, with little time or energy to waste of the staples of post-apocalyptic fiction: warlords, societal breakdown, and descent of our humanity to that of the animals, leading us to prey upon our fellow man. While there may be a few sociopaths who try to benefit from the situation, I expect the rest of us to quickly control that. Essentially, humanity has lived through these sorts of things in the past, and I am sure we would make do and get on with living in the aftermath of whatever mother nature sends our way again.
My very first program was 'hello world' in Basic on the High School computer lab's Apple ][ in 1981 (learned Fortran in that same course). I got a TI 99A for my birthday that year, and I wrote more noddy programs in Basic over the next few years, saving them meticulously on cassette tape.
I can't imagine using Basic for anything useful these days, but it was fun while it lasted.
Do not feed the trolls.
Another aspect of the problem - Corporate policy in most large companies is to treat all of your IT programmers as identical widgets. This policy stems from HR, Finance, and IT efforts to 'normalize' positions so they can be circumscribed enough to allow 'efficient' allocation of resources, or more damaging, the allocation of resources that can be outsourced wholesale. Ultimately it all comes down to cost reduction. Poor results of IT, coupled with IT being strictly a cost center - leads to this outcome (the cost vs. value proposition as seen through the eyes of the heads of the business).
This of course, drags down everyone with it causing many good people to leave or get caught in the outsourcing net. If they are lucky - they do manage to move up into management (architects etc) - and hopefully they can influence the designs - but again - what is left behind is tragically impossible of effiently implementing even the best designs - so the problem feeds itself as your best get pulled away from programming.
Indications are CTOs are starting to see how this is not working...here's hoping they can get the HR and Finance people to turn this around, but I doubt it. .