The next mayor improvement would be if that device was syncable . That way you could set up multiple devices and do MIMO. That's just a tiny thing, but could make a huge difference. Also ditch that USB port. If you have ever used an USRP you can see that it's mayor flaw is the USB port which is just to slow and unreliable to do anything useful with it. Use Ethernet.
Simply put, in order to pull that off, you'll need fairly sophisticated data processing, simply pointing 2 directional antennas at each other works fine outside, but is much more problematic in a data center which has walls and obstacles creating reflections. So what you could do is to use modern MIMO systems, but that would require huge amounts of processing power to get any kind of decent bandwidth. It's no point designing a system now which already peaks out at 10 GBit.
And it's very hard to subvert that. Whatever kind of technology you give to them, it _will_ be used to kill people first, then maybe for other users.
Other ideas which would be beneficial to the world will probably be ignored. I mean the US is spending close to $700 Billion on "defence". If you'd simply divide that by 7 Billion (number of people), you can give everyone $100 a year, enough to afford them basic education. Or we could probably even settle on the moon and work on interstellar flight.
Well yes, you can export it. It'll still be in a hard to read format since it'll also export headers and such. And still usually you don't even have a command-line tool for that so it's fairly useless for automation.
Essentially Spreadsheets have 3 problems in this context:
1. They look simple enough so people who should perhaps not make hard decisions believe they can out source their decisions to a spreadsheet.
2. They are fairly opaque. It's hard to look into the structure of a spreadsheet. All you see is the data. When you are programming what you see is the code. You see what your program is doing. Even if you look at the formulas inside your spreadsheet, you'll have variable names like A15. That's not particularly readable.
3. They are hard to maintain. Imagine you having 15 values to add. Now you want to change that program to add up 20 values. In normal programming languages that is just changing one value. On a spreadsheet you now need to change all instances where that array is mentioned. You have no chance of using a constant or searching for "15". It is very likely you miss one thing you should have changed.
And there's another problem which isn't relevant here, but you should consider none the less when thinking about spreadsheets. Spreadsheets lock their data in complex formats. If you are lucky you can get the data out as some sort of XML, if you are not, it's a binary blob. In any case, should you ever want to access the data with your own programme, you'll probably need to spend more time on getting the data than processing it.
As far as I know, the original Visicalc did some of the things right, so it actually was a moderately useful tool. For example as far as I know, it didn't allow you to scroll. That way the number of cells was limited to the amount of screen space you had... which was not a lot on an Apple II. Nobody would ever get the idea of having 10k data points in a Visicalc sheet, it simply was not possible.
I'm sorry, but the DSLAM is typically connected via fibre. Unless your ISP is a cheapskate they are going to put in the minimal cost it takes up upgrade it so the peak utilisation (and that's what's relevant here) stays below 50%. Peak utilisation obviously rises with time, so the ISP needs to continuously upgrade their network. That's what I pay it for.
Bandwidth doesn't cost much when it comes via fibre. The difference between a Gigabit or 10 Gigabits is just a different module in your router. You can upgrade the line to the DSLAM trivially. Whereas once your segment is full, there's nothing (within reason) you can do against it. Even if you can split up your segment, chances are you need to do it somewhere on a roadside where you don't have any fibre.
BTW the data rates you see advertised on standards like DOCSIS are the maximum rates the standard is designed for. In reality it greatly depends how rotten your lines are and how badly maintained the amplifiers in between are. Just because a standard allows you to do QAM1024 it doesn't mean it'll actually work in real life.
Well for the consumer market wired Ethernet certainly is an alternative. However think of conferences. Putting an access point up high near the ceiling in every room will get you decent coverage.
Actually that heavily depends on your ISP, while cable always is shared, DSL is not. Considering that most of the costs of DSL are at the last mile, good ISPs design their network so there will be no congestions in the typical peak hour of the day. And that is a moving target, a good ISP will upgrade their networks once it turns out more and more people are using streaming video.
Of course there are also ISPs run by people who want to squeeze every last penny out of the business.
Depending on your situation, the signal range of WLAN can often be far to great. If you get WLAN to work only within a single room, you can have a new "cell" in every room. Which means you can have way more cells and serve more people at a higher bandwidth.
When you actually need more range, you can always use directional antennas. Of course 60 GHz is attenuated quite a bit by air, so it's certainly unsuitable for outside microwave links.
is to target the "I want something Debian-like" customers, and brand it as a tool. Different tools have different uses. Instead of trying to turn MeeGo into a screwdriver (i.e. something Android/iOS/WP/Blackberry like) they should focus on its strengths and market it accordingly.
No, if you are an Android/iOS/WP/Blackberry-fan, Meego is probably not what you want. Unless of course they try to change Meego into yet another clone of that concept, then you will probably still not like it because there aren't enough apps, plus they will alienate their actual market.
Again, their actual market doesn't want apps, they want a distributions. They want to be able to have access to Debian Packages, not fart apps.
I'm not talking about connecting end switches via text-based protocols. And I never have. I have been talking about "sensors" as in "smart meters". There it makes sense. There you transmit data over some non-closed network. Again, I'm not talking about valves and servos.
If you cannot get IT working in such critical infrastructures, don't blame the people who are telling you what you are doing wrong. Besides where is the problem building a PLC sending its output variables as text? Furthermore, in the example of the company mentioned in the article, the smart meters probably didn't have a PLC connected to them. They were probably small devices with a micro controller.
Again, it's all fine and dandy if you connect your PLCs via a ProfiBus or whatever, but once it involves actual IT, you will have to play by the rules of good IT. (Of course there's a _lot_ of bad IT)
I mean look at SCADA. The whole field seems to be staffed by idiots. They think that OPC (OLE for Process Control) is a good idea, they still use that, even though the networking component works via DCOM, and it's all Windows only.
I mean a sane person would go and have sensors spit out text. That text can then be easily processed and archived easily. You can even batch process it, if you want. You can of course, also pour it into some SQL database if you prefer to, but having your primary data as text means that you can easily change your database engine without having to worry about compatibility.
For OPC you need additional software just to be able to archive it.
A simple (non-XML) format also would have the advantage of being easy to parse. You might, for example have a little single line header, having the number of the meter in it. Then you have each line representing a measurement point. First column could be the time in Unix epochs, then a space, then the measurement values. Such a format can easily be parsed, quicker than it can be read from RAM and without the danger of buffer overruns.
One should note that in fact large companies already have the source to their software, simply because they developed it themselves. If you are an Airline in the 1960s you couldn't just go to a store and buy a seat reservation system. You bought a computer, and hired some programmers and operators and wrote it yourself. The idea of going to a store with your lawyers and buying some software is actually fairly new.
Hmm... just try to buy a new version of Multics, or SCO Unix. Often simply hiring a programmer which makes the minimal changes to keep your old obsolete software running are much cheaper than switching to something new.
Just look at companies still using Windows XP because they need IE6. Switching their old legacy software to something new simply is to expensive.
Since open source software, at least when you carefully choose it, won't get obsolete as quickly, and even when it does and all fails, you can simply hire some programmers to maintain it for you.
However we are talking about management here. It is not wise to select the most rational solution inside a company. Everybody can find the most rational solution to a problem. If you make rational decisions in a management position you are easily replaced.
Such high innovation high risk activities used to be way more common till the 1980s. Look around you, Home Computers were made long before anybody believed there was a market for them, yet in the 1970s many companies just made and sold them. They did sell and a new industry was born.
Unfortunately that is a lot rarer now. Company only develop and build devices which are already proven to have a market. That's why there are virtually no new devices out there. The mobile device market, for example, is now more boring than it ever was. Virtually all the devices are precisely the same.
Remove dbus, remove pulseaudio and you are slowly getting towards it. Then try to get rid of any "low speed" interface (i.e. changing status of an IM-client) which require linking to libraries.
In the long run, I would make it file system based. You get a virtual file system representing GUI elements. Each of those elements would have a text based interface to make it easy to be used by shell scripts. Things that do need to be fast would use an additional binary interface. Network transparency will be done via NFS. Locally this works via shared memory.
Whenever you need to link a library to interface to something else, rethink that interface. Linking 2 C programs is very unstable. Even a slight change in the Interface makes it incompatible. Some form of text based interface will be much more stable.
Binary formats are necessary for certain types of high speed data transfer and processing, like video for example. However the rest can be done by simple column based text files or XML if you need complex structures.
First of all full ACK to rickb928. Maybe for extra bonus you could get them a Windows XP Professional box and ask them to change the file permissions on a file.
But in general you should be able to easily weed out those 99.999% of Windows "experts" who know nothing more about Windows than your users.
I think it was Spring 2011 "Why I like E-Books". There's also the case of hackers working for the military in the US. This is seen as something highly immoral in Germany. You just don't do that by accident or if you are a sociopath.
There's even the idea that if you have some, let's say IT security company, you're better off not having a customer than a governmental customer. Since when you are not having a customer you can at least search for customers, whereas if you have a governmental, perhaps even military customer, it will be much harder to get other customers.
I've been at one of the smaller hacker camps in Europe recently. There were literally stacks of notebooks lying around. Not a single one got stolen or damaged or whatever.
Of course I cannot speak for US hackers, I have read articles praising DRM in 2600, so it might be different there.
I don't mind animated GIFs, but Flash goes several steps to far. I draw the line at executing code provided by them. Period. If you want to reach me, use animated GIFs or text.
Slashdot Mirror
The next mayor improvement would be if that device was syncable . That way you could set up multiple devices and do MIMO. That's just a tiny thing, but could make a huge difference.
Also ditch that USB port. If you have ever used an USRP you can see that it's mayor flaw is the USB port which is just to slow and unreliable to do anything useful with it. Use Ethernet.
Simply put, in order to pull that off, you'll need fairly sophisticated data processing, simply pointing 2 directional antennas at each other works fine outside, but is much more problematic in a data center which has walls and obstacles creating reflections. So what you could do is to use modern MIMO systems, but that would require huge amounts of processing power to get any kind of decent bandwidth. It's no point designing a system now which already peaks out at 10 GBit.
And it's very hard to subvert that. Whatever kind of technology you give to them, it _will_ be used to kill people first, then maybe for other users.
Other ideas which would be beneficial to the world will probably be ignored. I mean the US is spending close to $700 Billion on "defence". If you'd simply divide that by 7 Billion (number of people), you can give everyone $100 a year, enough to afford them basic education. Or we could probably even settle on the moon and work on interstellar flight.
Well yes, you can export it. It'll still be in a hard to read format since it'll also export headers and such. And still usually you don't even have a command-line tool for that so it's fairly useless for automation.
That argument is like saying we should build houses out of loose straw since houses made out of stone also collapse.
You are comparing something as trivial as some business decision with something that is, literally, rocket science.
Essentially Spreadsheets have 3 problems in this context:
1. They look simple enough so people who should perhaps not make hard decisions believe they can out source their decisions to a spreadsheet.
2. They are fairly opaque. It's hard to look into the structure of a spreadsheet. All you see is the data. When you are programming what you see is the code. You see what your program is doing. Even if you look at the formulas inside your spreadsheet, you'll have variable names like A15. That's not particularly readable.
3. They are hard to maintain. Imagine you having 15 values to add. Now you want to change that program to add up 20 values. In normal programming languages that is just changing one value. On a spreadsheet you now need to change all instances where that array is mentioned. You have no chance of using a constant or searching for "15". It is very likely you miss one thing you should have changed.
And there's another problem which isn't relevant here, but you should consider none the less when thinking about spreadsheets.
Spreadsheets lock their data in complex formats. If you are lucky you can get the data out as some sort of XML, if you are not, it's a binary blob. In any case, should you ever want to access the data with your own programme, you'll probably need to spend more time on getting the data than processing it.
As far as I know, the original Visicalc did some of the things right, so it actually was a moderately useful tool. For example as far as I know, it didn't allow you to scroll. That way the number of cells was limited to the amount of screen space you had... which was not a lot on an Apple II. Nobody would ever get the idea of having 10k data points in a Visicalc sheet, it simply was not possible.
I'm sorry, but the DSLAM is typically connected via fibre. Unless your ISP is a cheapskate they are going to put in the minimal cost it takes up upgrade it so the peak utilisation (and that's what's relevant here) stays below 50%. Peak utilisation obviously rises with time, so the ISP needs to continuously upgrade their network. That's what I pay it for.
Bandwidth doesn't cost much when it comes via fibre. The difference between a Gigabit or 10 Gigabits is just a different module in your router. You can upgrade the line to the DSLAM trivially. Whereas once your segment is full, there's nothing (within reason) you can do against it. Even if you can split up your segment, chances are you need to do it somewhere on a roadside where you don't have any fibre.
BTW the data rates you see advertised on standards like DOCSIS are the maximum rates the standard is designed for. In reality it greatly depends how rotten your lines are and how badly maintained the amplifiers in between are. Just because a standard allows you to do QAM1024 it doesn't mean it'll actually work in real life.
Well for the consumer market wired Ethernet certainly is an alternative. However think of conferences. Putting an access point up high near the ceiling in every room will get you decent coverage.
Actually that heavily depends on your ISP, while cable always is shared, DSL is not. Considering that most of the costs of DSL are at the last mile, good ISPs design their network so there will be no congestions in the typical peak hour of the day. And that is a moving target, a good ISP will upgrade their networks once it turns out more and more people are using streaming video.
Of course there are also ISPs run by people who want to squeeze every last penny out of the business.
Depending on your situation, the signal range of WLAN can often be far to great. If you get WLAN to work only within a single room, you can have a new "cell" in every room. Which means you can have way more cells and serve more people at a higher bandwidth.
When you actually need more range, you can always use directional antennas. Of course 60 GHz is attenuated quite a bit by air, so it's certainly unsuitable for outside microwave links.
is to target the "I want something Debian-like" customers, and brand it as a tool. Different tools have different uses. Instead of trying to turn MeeGo into a screwdriver (i.e. something Android/iOS/WP/Blackberry like) they should focus on its strengths and market it accordingly.
No, if you are an Android/iOS/WP/Blackberry-fan, Meego is probably not what you want. Unless of course they try to change Meego into yet another clone of that concept, then you will probably still not like it because there aren't enough apps, plus they will alienate their actual market.
Again, their actual market doesn't want apps, they want a distributions. They want to be able to have access to Debian Packages, not fart apps.
I'm not talking about connecting end switches via text-based protocols. And I never have. I have been talking about "sensors" as in "smart meters". There it makes sense. There you transmit data over some non-closed network. Again, I'm not talking about valves and servos.
Please stop acknowledging my prejudices.
If you cannot get IT working in such critical infrastructures, don't blame the people who are telling you what you are doing wrong.
Besides where is the problem building a PLC sending its output variables as text?
Furthermore, in the example of the company mentioned in the article, the smart meters probably didn't have a PLC connected to them. They were probably small devices with a micro controller.
Again, it's all fine and dandy if you connect your PLCs via a ProfiBus or whatever, but once it involves actual IT, you will have to play by the rules of good IT. (Of course there's a _lot_ of bad IT)
I mean look at SCADA. The whole field seems to be staffed by idiots.
They think that OPC (OLE for Process Control) is a good idea, they still use that, even though the networking component works via DCOM, and it's all Windows only.
I mean a sane person would go and have sensors spit out text. That text can then be easily processed and archived easily. You can even batch process it, if you want.
You can of course, also pour it into some SQL database if you prefer to, but having your primary data as text means that you can easily change your database engine without having to worry about compatibility.
For OPC you need additional software just to be able to archive it.
A simple (non-XML) format also would have the advantage of being easy to parse. You might, for example have a little single line header, having the number of the meter in it. Then you have each line representing a measurement point. First column could be the time in Unix epochs, then a space, then the measurement values. Such a format can easily be parsed, quicker than it can be read from RAM and without the danger of buffer overruns.
One should note that in fact large companies already have the source to their software, simply because they developed it themselves. If you are an Airline in the 1960s you couldn't just go to a store and buy a seat reservation system. You bought a computer, and hired some programmers and operators and wrote it yourself. The idea of going to a store with your lawyers and buying some software is actually fairly new.
Hmm... just try to buy a new version of Multics, or SCO Unix. Often simply hiring a programmer which makes the minimal changes to keep your old obsolete software running are much cheaper than switching to something new.
Just look at companies still using Windows XP because they need IE6. Switching their old legacy software to something new simply is to expensive.
Since open source software, at least when you carefully choose it, won't get obsolete as quickly, and even when it does and all fails, you can simply hire some programmers to maintain it for you.
However we are talking about management here. It is not wise to select the most rational solution inside a company. Everybody can find the most rational solution to a problem. If you make rational decisions in a management position you are easily replaced.
Such high innovation high risk activities used to be way more common till the 1980s. Look around you, Home Computers were made long before anybody believed there was a market for them, yet in the 1970s many companies just made and sold them. They did sell and a new industry was born.
Unfortunately that is a lot rarer now. Company only develop and build devices which are already proven to have a market. That's why there are virtually no new devices out there. The mobile device market, for example, is now more boring than it ever was. Virtually all the devices are precisely the same.
Of course! Maybe there will be a move to Plan 9 in the near future.
Try to live by the Unix philosophy.
Remove dbus, remove pulseaudio and you are slowly getting towards it. Then try to get rid of any "low speed" interface (i.e. changing status of an IM-client) which require linking to libraries.
In the long run, I would make it file system based. You get a virtual file system representing GUI elements. Each of those elements would have a text based interface to make it easy to be used by shell scripts. Things that do need to be fast would use an additional binary interface. Network transparency will be done via NFS. Locally this works via shared memory.
Whenever you need to link a library to interface to something else, rethink that interface. Linking 2 C programs is very unstable. Even a slight change in the Interface makes it incompatible. Some form of text based interface will be much more stable.
Binary formats are necessary for certain types of high speed data transfer and processing, like video for example. However the rest can be done by simple column based text files or XML if you need complex structures.
First of all full ACK to rickb928.
Maybe for extra bonus you could get them a Windows XP Professional box and ask them to change the file permissions on a file.
But in general you should be able to easily weed out those 99.999% of Windows "experts" who know nothing more about Windows than your users.
I think it was Spring 2011 "Why I like E-Books".
There's also the case of hackers working for the military in the US. This is seen as something highly immoral in Germany. You just don't do that by accident or if you are a sociopath.
There's even the idea that if you have some, let's say IT security company, you're better off not having a customer than a governmental customer. Since when you are not having a customer you can at least search for customers, whereas if you have a governmental, perhaps even military customer, it will be much harder to get other customers.
I've been at one of the smaller hacker camps in Europe recently. There were literally stacks of notebooks lying around. Not a single one got stolen or damaged or whatever.
Of course I cannot speak for US hackers, I have read articles praising DRM in 2600, so it might be different there.
Absolutely. Although it's most likely the DRM provider will hit the bucket before you.
There is in short no non-idiotic advantage of DRM.
I don't mind animated GIFs, but Flash goes several steps to far. I draw the line at executing code provided by them. Period. If you want to reach me, use animated GIFs or text.