Bullshit. I had someone running a legacy app from a machine with only a 10Mb/s connection the other day. It worked as if he was running it locally. We're now in the age of gigabit.
Legacy apps are not a problem. Why would I want to run legacy apps? This is 2013, I want remote rendering of modern apps. And I get it, just not with X. Modern GNOME can run a composited desktop remotely over VNC with reasonable performance.
Don't blame your wireless network hassles on something else.
I have no wireless network hassles, it works flawlessly for everything else, and the latency to the server is typically below 5ms.
VNC is one to one and X is many to one. If you want to do things on only one remote machine at a time, VNC gets the job done with a bit of annoyance (eg. prevention of anyone using the local display on the remote machine)
I can run as many or few VNC server instances as I want. No local display involved, unless I want there to be one (and so far I have not wanted to). The local display is busy doing something else.
As to single window, X is not the only remote display protocol which supports "rootless" mode.
Come on, X was never part of the ideology of Unix. If it had been, it would at least have had native support for programs interacting, in order to make it possible to use multiple simple programs to achieve a complex task.
Like IPv4, it was an experiment which escaped from the lab. Today we can do better.
Whether Wayland is genuinely better I do not know, I have not tried it. X does need a new protocol though, and you cannot really call it X anymore if the protocol changes.
How do you get decent performance from remote X? Even on my home server from my notebook, with a wireless link typically running at least 100Mbps, performance in ssh -Y is so bad that makemkv is barely usable. Sometimes it takes several seconds for widgets to render. Remote X became almost useless for me at approximately the time that most programs switched to client-side rendering. Client-side rendering is a great leap forward that I would happily sacrifice network transparency to get, of course, so I am not saying that the switch was a bad idea.
Supposedly NX solves the speed problem, but if I have to run a third-party tool anyway, why pick NX instead of VNC or one of the other alternative protocols? RealVNC is already working on supporting Wayland.
SysV init scripts are horrible and fragile and were in desperate need of replacement. It is difficult to imagine that any replacement could be worse. systemd made a good effort at achieving just that, with weird auto-mounts as well as hangs or reboots during boot without any diagnostic output to the console.
Extra bonus for inventing journalctl, which is not about journaling or control, and which invokes the pager with wrong options by default. When you pipe the output to cat in desperation to avoid the horrible defaults, you do not get the same output.
systemd is not the reason why I abandoned Linux on the desktop, but it certainly did not help the situation.
Sector writes are atomic because they can only be read in their entirety. The encoding of each bit depends on the contents of the surrounding bits. If half a sector is written, neither the old nor the new half will be readable.
Now, modern spinning rust drives have 4kiB physical sectors and emulate 512B sectors via read-modify-write. Think about the failure modes and cry. The solution is to use 4kiB sectors natively, but Windows 8 is the first Microsoft operating system to support that.
SSDs work entirely differently with their own interesting failure modes (but they will have use HDD-like encodings if density keeps increasing).
If your only dependency is glibc, you are pretty much golden. glibc is almost as good at backwards compatibility as the kernel and has been for at least a decade.
For sound in games on Linux you want SDL. It is under the zlib license which is new-style BSD-like, so licensing is not a problem. Requiring SDL 2.0 should not be a problem on anything even remotely modern.
I would pick grid power over a $43 UPS any day. Besides, how are you going to manage 200 UPSs? Will someone react to battery alarms at all the sites?
In my experience user error are by far the most common causes of power failure, particularly for systems without strict physical access restrictions. The UPS is unlikely to prevent user error and the added equipment may in fact make it more likely that someone does something stupid.
You cannot use a Linux distribution. None of them provide a platform you can develop against and expect your GUI applications to remain working in a year or two. Unless you completely ignore the system libraries and bring in everything yourself, that is, but in that case you have lost integration with the native desktop and users are likely to notice that. In contrast, most apps developed for Android 2.x run on 4.4 and do not look badly out of place (admittedly that is easier to achieve when all applications are full-screen-only).
The Linux kernel values backwards compatibility with user applications higher than almost any other concern. Alas, the system libraries and desktop environments do not have such concerns -- after all, you can just parallel install older versions of the libraries, so why make the newer ones compatible? Distribution developers similarly do not feel that backwards compatibility is their problem to handle, and maintaining multiple versions of libraries requires too much manpower anyway.
Anyway, the end result is that when you pick a Linux distribution, you also choose to use exactly the software available for that particular distribution (including third party repositories of course). Third party developers need to lobby every distribution to include their software or face the maintenance burden themselves for each current version of every distribution.
Fair enough, you go ahead and put new fiber in the ground. Meanwhile the incumbents will offer G.fast at very little cost to them, because the copper investment has long since been paid off. Fiber is absolutely a better product, and you will undoubtedly be able to steal some customers who hate the higher latency of G.fast or feel cheated when their supposedly 1Gbps line only delivers 1Gbps when doing speed tests, never in actual use.
However, it is tricky to survive long enough for potential customers to understand the benefits, especially when your competitors can dump prices to near zero without even losing money. If the competitors are allowed to lie it gets even worse, like in the UK. According to adverts, I can get 100Mbps fiber from Virgin which is actually DOCSIS or 80Mbps fiber from BT which is actually VDSL.
That does not really have anything to do with equipment upgrades at the central sites. Going from ADSL1 to G.fast in the city is mostly a matter of replacing line cards and DSLAMs. Putting new wires into the ground is an entirely different prospect.
Fair enough on the line pairs, but the head end equipment seems to be more expensive than VDSL2 DSLAMs -- and you need at least twice as many ports if you want to bundle. I do not know the actual prices though. The CPEs seem rather more expensive too.
The only actual experience with G.SHDSL.bis was playing in a lab with OneAccess routers. Those are certainly more expensive than a typical CPE for home use, but they also have more features.
Band together with your neighbors and share a fiber through wireless links (or more fiber if it is possible to get digging permits). It is a bother, but it is pretty much your only chance. It tends to require a fairly tight knit community to work well, but in some cases it manages to bring the community together.
How? It has been a long time since there was any significant improvement in performance when the wires are longer than 1 km. ADSL2+, VDSL1, and VDSL2 perform about equally badly beyond that distance. You can go faster by doing G.SHDSL over multiple line pairs, but that is generally not economical.
Doesn't it count as a feedback effect even if the constant is such that it cannot run away on its own? After all, the increased warming due to wetter air leads to even wetter air.
True, but emitting more water into the atmosphere generally does not increase overall water content of the air significantly. If you do not change the temperature, the water will just fall back out. If you do increase the temperature, the air tends to find a way to gather more humidity, whether you add any deliberately or not.
Having a national constitution which makes it impossible to implement a charter does not absolve a member state from implementing the charter.
However, the EU can only apply fines or (maybe, theoretically) throw member states out of the union, and it remains to be seen just how large a fine can be without provoking too much dissent. Probably not very large if it is the UK that gets fined...
The attack has no complexity. All you save the attacker by not running F2 for them is obscurity, the attacker does not have to spend any computational resources, they just have to know F2.
The security of modern cryptosystems is in the key, not in the obscurity of the algorithms or (at least not intentionally) the attacks.
The attacker knows the algorithms in use. The attacker can just run F2 himself, it costs only a small constant time. If F2 exposes a flaw in F1, that flaw was already there from the start.
Well, you live in such a world, whether you like it or not.
If the recipient honestly believes they were the victim of the company trying to get them to pay for something they did not order, they have a chance to keep the item. How many of the recipients believe that?
Combining two encryption methods using separate keys can never be weaker than the inner encryption. Proof: if the combined method IS weaker, the attacker could just use the outer method as an attack with a small constant complexity on the inner method, which means the inner method is exactly as strong as the combined method (times a small constant). Unfortunately the same does not apply to the outer method, it is possible for a weak inner method to defeat the security of a strong outer method (e.g. if the inner method always starts its output with a known pattern, it can really mess up your outer method). Therefore, always encrypt FIRST with the algorithm you trust most, and NEVER use the same key for both methods.
Before DES became the practically universal standard, there were multiple very similar algorithms in use, with the most significant difference being the S-boxes. At least one of them turned out to be breakable with 2^2 effort. Even s2des (I would do a superscript 2 but Slashdot is stuck in the 90's) which was specifically designed to be more resistant to differential attacks turned out to be MORE vulnerable to those attacks.
Slashdot Mirror
Bullshit. I had someone running a legacy app from a machine with only a 10Mb/s connection the other day. It worked as if he was running it locally. We're now in the age of gigabit.
Legacy apps are not a problem. Why would I want to run legacy apps? This is 2013, I want remote rendering of modern apps. And I get it, just not with X. Modern GNOME can run a composited desktop remotely over VNC with reasonable performance.
Don't blame your wireless network hassles on something else.
I have no wireless network hassles, it works flawlessly for everything else, and the latency to the server is typically below 5ms.
VNC is one to one and X is many to one. If you want to do things on only one remote machine at a time, VNC gets the job done with a bit of annoyance (eg. prevention of anyone using the local display on the remote machine)
I can run as many or few VNC server instances as I want. No local display involved, unless I want there to be one (and so far I have not wanted to). The local display is busy doing something else.
As to single window, X is not the only remote display protocol which supports "rootless" mode.
Come on, X was never part of the ideology of Unix. If it had been, it would at least have had native support for programs interacting, in order to make it possible to use multiple simple programs to achieve a complex task.
Like IPv4, it was an experiment which escaped from the lab. Today we can do better.
Whether Wayland is genuinely better I do not know, I have not tried it. X does need a new protocol though, and you cannot really call it X anymore if the protocol changes.
How do you get decent performance from remote X? Even on my home server from my notebook, with a wireless link typically running at least 100Mbps, performance in ssh -Y is so bad that makemkv is barely usable. Sometimes it takes several seconds for widgets to render. Remote X became almost useless for me at approximately the time that most programs switched to client-side rendering. Client-side rendering is a great leap forward that I would happily sacrifice network transparency to get, of course, so I am not saying that the switch was a bad idea.
Supposedly NX solves the speed problem, but if I have to run a third-party tool anyway, why pick NX instead of VNC or one of the other alternative protocols? RealVNC is already working on supporting Wayland.
SysV init scripts are horrible and fragile and were in desperate need of replacement. It is difficult to imagine that any replacement could be worse. systemd made a good effort at achieving just that, with weird auto-mounts as well as hangs or reboots during boot without any diagnostic output to the console.
Extra bonus for inventing journalctl, which is not about journaling or control, and which invokes the pager with wrong options by default. When you pipe the output to cat in desperation to avoid the horrible defaults, you do not get the same output.
systemd is not the reason why I abandoned Linux on the desktop, but it certainly did not help the situation.
Sector writes are atomic because they can only be read in their entirety. The encoding of each bit depends on the contents of the surrounding bits. If half a sector is written, neither the old nor the new half will be readable.
Now, modern spinning rust drives have 4kiB physical sectors and emulate 512B sectors via read-modify-write. Think about the failure modes and cry. The solution is to use 4kiB sectors natively, but Windows 8 is the first Microsoft operating system to support that.
SSDs work entirely differently with their own interesting failure modes (but they will have use HDD-like encodings if density keeps increasing).
If your only dependency is glibc, you are pretty much golden. glibc is almost as good at backwards compatibility as the kernel and has been for at least a decade.
For sound in games on Linux you want SDL. It is under the zlib license which is new-style BSD-like, so licensing is not a problem. Requiring SDL 2.0 should not be a problem on anything even remotely modern.
I would pick grid power over a $43 UPS any day. Besides, how are you going to manage 200 UPSs? Will someone react to battery alarms at all the sites?
In my experience user error are by far the most common causes of power failure, particularly for systems without strict physical access restrictions. The UPS is unlikely to prevent user error and the added equipment may in fact make it more likely that someone does something stupid.
You cannot use a Linux distribution. None of them provide a platform you can develop against and expect your GUI applications to remain working in a year or two. Unless you completely ignore the system libraries and bring in everything yourself, that is, but in that case you have lost integration with the native desktop and users are likely to notice that. In contrast, most apps developed for Android 2.x run on 4.4 and do not look badly out of place (admittedly that is easier to achieve when all applications are full-screen-only).
The Linux kernel values backwards compatibility with user applications higher than almost any other concern. Alas, the system libraries and desktop environments do not have such concerns -- after all, you can just parallel install older versions of the libraries, so why make the newer ones compatible? Distribution developers similarly do not feel that backwards compatibility is their problem to handle, and maintaining multiple versions of libraries requires too much manpower anyway.
Anyway, the end result is that when you pick a Linux distribution, you also choose to use exactly the software available for that particular distribution (including third party repositories of course). Third party developers need to lobby every distribution to include their software or face the maintenance burden themselves for each current version of every distribution.
Haven't you noticed that some of the spaces in the second and third copy are replaced by U+2002 EN SPACE or U+205F MEDIUM MATHEMATICAL SPACE?
Try making a diff and decoding the changes in trinary, you will find a secret note only for you.
I live in a house with resistance electric heating
Hopefully you will fix that problem too.
So buy the halogens or the "high efficiency" incandescents.
Pull out the copper network? Why? It is dirt cheap redundancy, why throw it away?
Fair enough, you go ahead and put new fiber in the ground. Meanwhile the incumbents will offer G.fast at very little cost to them, because the copper investment has long since been paid off. Fiber is absolutely a better product, and you will undoubtedly be able to steal some customers who hate the higher latency of G.fast or feel cheated when their supposedly 1Gbps line only delivers 1Gbps when doing speed tests, never in actual use.
However, it is tricky to survive long enough for potential customers to understand the benefits, especially when your competitors can dump prices to near zero without even losing money. If the competitors are allowed to lie it gets even worse, like in the UK. According to adverts, I can get 100Mbps fiber from Virgin which is actually DOCSIS or 80Mbps fiber from BT which is actually VDSL.
That does not really have anything to do with equipment upgrades at the central sites. Going from ADSL1 to G.fast in the city is mostly a matter of replacing line cards and DSLAMs. Putting new wires into the ground is an entirely different prospect.
Fair enough on the line pairs, but the head end equipment seems to be more expensive than VDSL2 DSLAMs -- and you need at least twice as many ports if you want to bundle. I do not know the actual prices though. The CPEs seem rather more expensive too.
The only actual experience with G.SHDSL.bis was playing in a lab with OneAccess routers. Those are certainly more expensive than a typical CPE for home use, but they also have more features.
Band together with your neighbors and share a fiber through wireless links (or more fiber if it is possible to get digging permits). It is a bother, but it is pretty much your only chance. It tends to require a fairly tight knit community to work well, but in some cases it manages to bring the community together.
How? It has been a long time since there was any significant improvement in performance when the wires are longer than 1 km. ADSL2+, VDSL1, and VDSL2 perform about equally badly beyond that distance. You can go faster by doing G.SHDSL over multiple line pairs, but that is generally not economical.
Doesn't it count as a feedback effect even if the constant is such that it cannot run away on its own? After all, the increased warming due to wetter air leads to even wetter air.
True, but emitting more water into the atmosphere generally does not increase overall water content of the air significantly. If you do not change the temperature, the water will just fall back out. If you do increase the temperature, the air tends to find a way to gather more humidity, whether you add any deliberately or not.
Having a national constitution which makes it impossible to implement a charter does not absolve a member state from implementing the charter.
However, the EU can only apply fines or (maybe, theoretically) throw member states out of the union, and it remains to be seen just how large a fine can be without provoking too much dissent. Probably not very large if it is the UK that gets fined...
The attack has no complexity. All you save the attacker by not running F2 for them is obscurity, the attacker does not have to spend any computational resources, they just have to know F2.
The security of modern cryptosystems is in the key, not in the obscurity of the algorithms or (at least not intentionally) the attacks.
The attacker knows the algorithms in use. The attacker can just run F2 himself, it costs only a small constant time. If F2 exposes a flaw in F1, that flaw was already there from the start.
Well, you live in such a world, whether you like it or not.
If the recipient honestly believes they were the victim of the company trying to get them to pay for something they did not order, they have a chance to keep the item. How many of the recipients believe that?
Combining two encryption methods using separate keys can never be weaker than the inner encryption. Proof: if the combined method IS weaker, the attacker could just use the outer method as an attack with a small constant complexity on the inner method, which means the inner method is exactly as strong as the combined method (times a small constant). Unfortunately the same does not apply to the outer method, it is possible for a weak inner method to defeat the security of a strong outer method (e.g. if the inner method always starts its output with a known pattern, it can really mess up your outer method). Therefore, always encrypt FIRST with the algorithm you trust most, and NEVER use the same key for both methods.
Before DES became the practically universal standard, there were multiple very similar algorithms in use, with the most significant difference being the S-boxes. At least one of them turned out to be breakable with 2^2 effort. Even s2des (I would do a superscript 2 but Slashdot is stuck in the 90's) which was specifically designed to be more resistant to differential attacks turned out to be MORE vulnerable to those attacks.
Minor tweaks are worrying.