Comparing the Apple Newton and the iPhone... I'd say that the iCar would be a car that's well connected and essentially controlled by Apple. It would not work on roads not approved by Apple. It would probably be controlled by a touch screen or voice. However it would not drive by itself, as that feature has been proven to be complicated. Of course it won't have a driving wheel, instead it'll have a software driving wheel on a large touch screen in front of you.
Functionality wise, the iPhone was a _huge_ step back from what the Newton could do.
There even used to be a 1980s calculator watch which used the watchface so you could draw on your digits. The technology is rather simple so it is a logical thing to do.
The problem is, while it works for calculators, writing complex command lines is much harder.
... and the reason why on other operating systems you have to escape spaces every time. This way you cannot have the ambiguity if you mean a path with a space, or a program and then a parameter.
In short you can expect most languages younger than 30 years to disappear soon. If a language doesn't have it's special reason to exist, it won't.
In case of COBOL and FORTRAN that was a huge amount of business critical code, as well as the possibility to simply run it on your next computer. C is seen as a "smart assembler". LISP and its family are great for logical processing. Java seems to become the new COBOL.
And there are 2 languages on the List which do have those special reasons. One is Perl, which is just a great tool for dealing with strings in a quick and dirty way, the other one is "Object Pascal" which, in it's original form with Delphi is dead, but lives in in FOSS projects like FreePascal and Lazarus, it has the great opportunity of having native code plus platform independent native GUIs. In short their way of doing GUI means that you can write a program on Linux, compile it on a Mac and it'll look and feel like a Mac program.
What will die soonish is of course the.net world as it completely depends on a single company... which doesn't use it for their important products.
.... you should _seriously_ consider getting a proper one. The number of concurrent connections should be _far_ higher than what you typically have, and the QoS should make SSH still go through like a charm.
This seems like something only useful for malware. After all the only reason you don't want the person to know what code they run is to do something they don't want you to do. And that's essentially the definition of malware.
After all its artificially limiting what you can do with the hardware. Plus it'll mean you'll have to run closed source firmware from the manufacturer on the device, which means that it'll probably contain malware. Why else would you distribute software in object code only? (No, competitors probably have reverse engineered it years ago.)
but this would mean it's efficiency would drop. If you make the filament thicker it won't get as hot and it'll last longer, however since it'll be cooler even more of it's radiation will be in the infrared and therefore lost for it's purpose. So if a manufacturer was to make longer lasting light blubs, they would be considerably dimmer and redder at the same power consumption.
The reason why LED lights give out quicker than advertised is because they are more heat sensitive. If you have a light fixture designed for light bulbs, chances are they are not well designed to keep them cool. However if your LED lights get to hot for extended periods of time, they will eventually break. Plus particularly with low quality ones, you have the problem of bad external components. However those failures are typically trivial to fix.
Well with systemd that probably will be a thing of the past. My guess is that for such minimalistic systems, people will go towards having their own simplified init. After all Linux is designed to allow you to have init as a shell script.
In a working democracy the public would be able to decide what to do with the tax money. However since in the US the democratic system is severely broken, it's not surprising parallel systems are starting to come up.
Well Apache, OpenOffice and PostgreSQL are perhaps not the prime examples of the Unix philosophy however... Apache stores all its logs and configuration, as well as much of its data in text files. It has one function and one function only, to reply to HTTP requests. OpenOffice isn't really Unix software, it's an office package. People following the Unix philosophy see those as a violation of it. PostgreSQL also does one thing. It processes SQL databases... and while it's using a binary format internally, all the interfaces are text based... in fact even the backup format is text.
But let's refute Poetterling while we are there:
"If you build systemd with all configuration options enabled you will build 69 individual binaries.": Yes, but how are the dependencies? Do they share the same huge set of bloated libraries? What will happen if, for example the DBUS library gets corrupted for some reason? How many vital libraries are there?
"Myth: systemd's fast boot-up is irrelevant for servers." He refutes that himself a few lines down: "Of course, in many server setups boot-up is indeed irrelevant"
I stopped reading there. Seriously Poetterling hasn't understood Unix, if he would he would understand that binary software is something only to be done if there's a serious reason for it.
1. Ever had to use AIX, Solaris or MacOSX? Do you know why so comparatively few people use those systems by choice?
2. Well yes, it's about the opinion that systems should be working well. So far there have been few systems getting you as much "bang for the buck" as Unix. And none of those use binary data formats with C or C++.
Well I can read a text format with cat. With a binary format I need to use special tools which may or may not be available depending on the state of brokenness. It's much more likely to get cat to run than whatever binary tool there is.
Well standard SysV init will only fail unless there are some serious problems... like being unable to mount the root file system... in those cases it will give you a helpful message on the console. And even if it fails, you are still typically left with/bin/sh if that can be loaded. That's good enough to diagnose and fix any SysV init problem.
The problem with systemd is that it is going back to the time when there were complex systems talking via binary interfaces. It introduces complexity without benefit. For example why does systemd have to be a binary? What advantage does that bring?
In a way systemd is the line that has to be drawn when it comes to useless bloat. People did tolerate pulseaudio and DBus to some degree, those are absolutely non essential services, but booting and logging is something essential. If your system won't boot and you won't have a decent way to fix it, you'll have a serious problem.
It's not Linux, it's the runtime system, so there is no need to fork... but I think it's about time for a distribution to actually take the Unix philosophy to heart and to throw out all that new crap.
The time when people who had no idea started to believe they could create something better then UNIX. This created the mess we had in the 1990s when it was OK to have log files in binary files and you could only view them through a small non-resizable window. A time when you could display the owners of open files on your network share... but you couldn't do anything with that info except for writing it down and manually act upon it. Of course that data was also displayed in a small non-resizable window.
There is a reason why normal init is based on shell scripts, and that reason is simply because there is no reason against it. Shell scripts are perfectly adequate for that job. Binaries on Unix however make it much more difficult to deal with them. If you want to edit a binary you have to get the source code, edit it, make it compile, and then hope it'll run. It's even worse when you have dynamically linked binaries since they depend on other files, particularly for init.
Binaries are just a botched solution to somehow get faster execution. The whole design of Unix doesn't require them. Unlike Windows you shouldn't need to link in a library to have some API you should instead have a little program you can call. (actually Windows now has a little wrapper allowing you to make arbitrary calls to DLLs since even Microsoft has recognized the problem)
Dynamically linked libraries are just a botched solution for the problem of library bloat. You shouldn't need them, if you want some feature you should just call the program implementing it. That's how bc worked originally. All the calculation functionality was in dc and bc just re-formated its input to what dc expects. The problem why this doesn't work well any more is long startup times caused by library bloat.
Well you can fix all the problems existing in current SoCs. For example you could build an architecture which enables you to have multiple SoC boot up from the same image, just like the PC does. You could have basic hardware support without binary blobs.
In essence you could create a new portable platform where you could, for example, swap out the operating system on your mobile phone just by putting another OS onto your SD-card. That way even if your vendor doesn't support your device anymore, you can still get the latest version of whatever operating system you want. In fact as it'll greatly simplify making distributions, you could even get specially tailored operating systems for your needs.
I hope the people doing this will understand their chance.
Eventually commercial companies will end up like Siemens. Decisions will gradually take longer and longer, causing more and more engineers to be needed. This means that more bad engineers enter the company so more rules need to be set in place so those won't mess up to much. This will make the good engineers frustrated so they leave.
What you end up with is a company where your good engineers constantly evaporate, and you end up paying ridiculous amounts of money just to keep the rest. Those people will then feel like they actually know something since there are no better people to learn left in that company and they are paid huge amounts of money. This enforces their Krüger-Dunning-Effect and makes them toxic.
They don't understand how things work and therefore believe their ridiculous ideas are actually good. Those ideas cause more work and more frustration for the few good people who drift into the company.
In the end you'll end up with a huge amount of highly paid idiots bringing out inferior products. Since there rarely is competition in the real world, the company will stay in business. Should the company be in competition it is, by that point, already to big to fail and therefore will be saved by the government.
Yes I'd use simple SIP video phones. There's no need to go to Skype. You can either have your own SIP server, or use one of the many SIP providers which can even give you connectivity to the public telephone network at decent prices, if you want.
It doesn't matter what the consumer wants. What matters is what operators and manufacturers want. There is no way manufacturers are going to get feedback from consumers on such complex things. All they get is sales numbers, but they have no idea why a certain product sells or not. That's why Blackberry added colour touch screens since they don't understand what the potential of their product is. They see Apple being successful with touchscreen phones and so also try touchscreen phones.
Of course you can always use the democratic aspect of capitalism and just buy a mobile phone company, and make them build whatever device you want.
It's an attempt to get the most "bang for the buck". Essentially you write lots of small programs which have limited and well defined functionality, then you hook them up any way you like. In fact taken to the extreme (as with Plan9) you can do anything with simple shell scripts.
BTW there are simpler developing environments out there which have a decent feature set, without the complexity of a C(++) toolchain. Lazarus is just one example of it. Of course you then loose flexibility. Lazarus, for example, is mostly suitable for GUI applications. Writing a webserver with it is hard. Of course it does GUI decently well, allowing you to have one codebase compiling from everything from your bog standard Linxux (GTK) over MacOSX, Android to even exotic platforms like Win32.
That's because those devices will, like "smart"-phones, cater to the lowest denominator. In the end you'll end up with a device that's hard to program, preventing "casual programming", while allowing malware via some store.
So far the closest thing I've seen to a smart watch was the HP-01.
Slashdot Mirror
Here's a German example for it:
http://www.youtube.com/watch?v...
Crash 2030 - Protokoll einer Katastrophe
Or if you like more alarmist ones which turned out to have been hugely wrong on some facts:
http://www.youtube.com/watch?v...
Studio Telerop 2009
Comparing the Apple Newton and the iPhone... I'd say that the iCar would be a car that's well connected and essentially controlled by Apple. It would not work on roads not approved by Apple. It would probably be controlled by a touch screen or voice. However it would not drive by itself, as that feature has been proven to be complicated. Of course it won't have a driving wheel, instead it'll have a software driving wheel on a large touch screen in front of you.
Functionality wise, the iPhone was a _huge_ step back from what the Newton could do.
There even used to be a 1980s calculator watch which used the watchface so you could draw on your digits. The technology is rather simple so it is a logical thing to do.
The problem is, while it works for calculators, writing complex command lines is much harder.
... and the reason why on other operating systems you have to escape spaces every time. This way you cannot have the ambiguity if you mean a path with a space, or a program and then a parameter.
In short you can expect most languages younger than 30 years to disappear soon.
If a language doesn't have it's special reason to exist, it won't.
In case of COBOL and FORTRAN that was a huge amount of business critical code, as well as the possibility to simply run it on your next computer. C is seen as a "smart assembler". LISP and its family are great for logical processing. Java seems to become the new COBOL.
And there are 2 languages on the List which do have those special reasons. One is Perl, which is just a great tool for dealing with strings in a quick and dirty way, the other one is "Object Pascal" which, in it's original form with Delphi is dead, but lives in in FOSS projects like FreePascal and Lazarus, it has the great opportunity of having native code plus platform independent native GUIs. In short their way of doing GUI means that you can write a program on Linux, compile it on a Mac and it'll look and feel like a Mac program.
What will die soonish is of course the .net world as it completely depends on a single company... which doesn't use it for their important products.
.... you should _seriously_ consider getting a proper one. The number of concurrent connections should be _far_ higher than what you typically have, and the QoS should make SSH still go through like a charm.
This seems like something only useful for malware. After all the only reason you don't want the person to know what code they run is to do something they don't want you to do. And that's essentially the definition of malware.
After all its artificially limiting what you can do with the hardware. Plus it'll mean you'll have to run closed source firmware from the manufacturer on the device, which means that it'll probably contain malware. Why else would you distribute software in object code only? (No, competitors probably have reverse engineered it years ago.)
but this would mean it's efficiency would drop. If you make the filament thicker it won't get as hot and it'll last longer, however since it'll be cooler even more of it's radiation will be in the infrared and therefore lost for it's purpose. So if a manufacturer was to make longer lasting light blubs, they would be considerably dimmer and redder at the same power consumption.
The reason why LED lights give out quicker than advertised is because they are more heat sensitive. If you have a light fixture designed for light bulbs, chances are they are not well designed to keep them cool. However if your LED lights get to hot for extended periods of time, they will eventually break. Plus particularly with low quality ones, you have the problem of bad external components. However those failures are typically trivial to fix.
Well with systemd that probably will be a thing of the past. My guess is that for such minimalistic systems, people will go towards having their own simplified init. After all Linux is designed to allow you to have init as a shell script.
In a working democracy the public would be able to decide what to do with the tax money. However since in the US the democratic system is severely broken, it's not surprising parallel systems are starting to come up.
Well Apache, OpenOffice and PostgreSQL are perhaps not the prime examples of the Unix philosophy however...
Apache stores all its logs and configuration, as well as much of its data in text files. It has one function and one function only, to reply to HTTP requests.
OpenOffice isn't really Unix software, it's an office package. People following the Unix philosophy see those as a violation of it.
PostgreSQL also does one thing. It processes SQL databases... and while it's using a binary format internally, all the interfaces are text based... in fact even the backup format is text.
But let's refute Poetterling while we are there:
"If you build systemd with all configuration options enabled you will build 69 individual binaries.":
Yes, but how are the dependencies? Do they share the same huge set of bloated libraries? What will happen if, for example the DBUS library gets corrupted for some reason? How many vital libraries are there?
"Myth: systemd's fast boot-up is irrelevant for servers." He refutes that himself a few lines down: "Of course, in many server setups boot-up is indeed irrelevant"
I stopped reading there. Seriously Poetterling hasn't understood Unix, if he would he would understand that binary software is something only to be done if there's a serious reason for it.
1. Ever had to use AIX, Solaris or MacOSX? Do you know why so comparatively few people use those systems by choice?
2. Well yes, it's about the opinion that systems should be working well. So far there have been few systems getting you as much "bang for the buck" as Unix. And none of those use binary data formats with C or C++.
Well I can read a text format with cat. With a binary format I need to use special tools which may or may not be available depending on the state of brokenness. It's much more likely to get cat to run than whatever binary tool there is.
Well standard SysV init will only fail unless there are some serious problems... like being unable to mount the root file system... in those cases it will give you a helpful message on the console. /bin/sh if that can be loaded. That's good enough to diagnose and fix any SysV init problem.
And even if it fails, you are still typically left with
The problem with systemd is that it is going back to the time when there were complex systems talking via binary interfaces. It introduces complexity without benefit. For example why does systemd have to be a binary? What advantage does that bring?
In a way systemd is the line that has to be drawn when it comes to useless bloat. People did tolerate pulseaudio and DBus to some degree, those are absolutely non essential services, but booting and logging is something essential. If your system won't boot and you won't have a decent way to fix it, you'll have a serious problem.
It's not Linux, it's the runtime system, so there is no need to fork... but I think it's about time for a distribution to actually take the Unix philosophy to heart and to throw out all that new crap.
The time when people who had no idea started to believe they could create something better then UNIX.
This created the mess we had in the 1990s when it was OK to have log files in binary files and you could only view them through a small non-resizable window. A time when you could display the owners of open files on your network share... but you couldn't do anything with that info except for writing it down and manually act upon it. Of course that data was also displayed in a small non-resizable window.
There is a reason why normal init is based on shell scripts, and that reason is simply because there is no reason against it. Shell scripts are perfectly adequate for that job. Binaries on Unix however make it much more difficult to deal with them. If you want to edit a binary you have to get the source code, edit it, make it compile, and then hope it'll run. It's even worse when you have dynamically linked binaries since they depend on other files, particularly for init.
Binaries are just a botched solution to somehow get faster execution. The whole design of Unix doesn't require them. Unlike Windows you shouldn't need to link in a library to have some API you should instead have a little program you can call. (actually Windows now has a little wrapper allowing you to make arbitrary calls to DLLs since even Microsoft has recognized the problem)
Dynamically linked libraries are just a botched solution for the problem of library bloat. You shouldn't need them, if you want some feature you should just call the program implementing it. That's how bc worked originally. All the calculation functionality was in dc and bc just re-formated its input to what dc expects. The problem why this doesn't work well any more is long startup times caused by library bloat.
Well you can fix all the problems existing in current SoCs. For example you could build an architecture which enables you to have multiple SoC boot up from the same image, just like the PC does. You could have basic hardware support without binary blobs.
In essence you could create a new portable platform where you could, for example, swap out the operating system on your mobile phone just by putting another OS onto your SD-card. That way even if your vendor doesn't support your device anymore, you can still get the latest version of whatever operating system you want. In fact as it'll greatly simplify making distributions, you could even get specially tailored operating systems for your needs.
I hope the people doing this will understand their chance.
Eventually commercial companies will end up like Siemens. Decisions will gradually take longer and longer, causing more and more engineers to be needed. This means that more bad engineers enter the company so more rules need to be set in place so those won't mess up to much. This will make the good engineers frustrated so they leave.
What you end up with is a company where your good engineers constantly evaporate, and you end up paying ridiculous amounts of money just to keep the rest. Those people will then feel like they actually know something since there are no better people to learn left in that company and they are paid huge amounts of money. This enforces their Krüger-Dunning-Effect and makes them toxic.
They don't understand how things work and therefore believe their ridiculous ideas are actually good. Those ideas cause more work and more frustration for the few good people who drift into the company.
In the end you'll end up with a huge amount of highly paid idiots bringing out inferior products. Since there rarely is competition in the real world, the company will stay in business. Should the company be in competition it is, by that point, already to big to fail and therefore will be saved by the government.
Yes I'd use simple SIP video phones. There's no need to go to Skype. You can either have your own SIP server, or use one of the many SIP providers which can even give you connectivity to the public telephone network at decent prices, if you want.
Ahh sorry, haven't seen that one yet.
Being a small stock holder is meaningless, you need a controlling share, or at least some noticeable share like 10%.
It doesn't matter what the consumer wants. What matters is what operators and manufacturers want. There is no way manufacturers are going to get feedback from consumers on such complex things. All they get is sales numbers, but they have no idea why a certain product sells or not. That's why Blackberry added colour touch screens since they don't understand what the potential of their product is. They see Apple being successful with touchscreen phones and so also try touchscreen phones.
Of course you can always use the democratic aspect of capitalism and just buy a mobile phone company, and make them build whatever device you want.
It's an attempt to get the most "bang for the buck". Essentially you write lots of small programs which have limited and well defined functionality, then you hook them up any way you like. In fact taken to the extreme (as with Plan9) you can do anything with simple shell scripts.
BTW there are simpler developing environments out there which have a decent feature set, without the complexity of a C(++) toolchain. Lazarus is just one example of it. Of course you then loose flexibility. Lazarus, for example, is mostly suitable for GUI applications. Writing a webserver with it is hard. Of course it does GUI decently well, allowing you to have one codebase compiling from everything from your bog standard Linxux (GTK) over MacOSX, Android to even exotic platforms like Win32.
That's because those devices will, like "smart"-phones, cater to the lowest denominator. In the end you'll end up with a device that's hard to program, preventing "casual programming", while allowing malware via some store.
So far the closest thing I've seen to a smart watch was the HP-01.