Nowadays, tracks are usually inspected with track inspection vehicles, which are fitted with a number of sensors and can inspect tracks at speeds of up to 50 km per hour (last time I checked). High speed rail tracks may be inspected several times per week, during the night.
I'm not aware of any practical maglev system which levitates by using magnetic repulsion against a simple sheet of metal (copper). Depending on how much power they're using and whether they can make it work with a cheaper metal than copper, this can be an interesting technology.
Their goal is to receive the packets into their own user space analysis software and drop most of them (as being a flood attack). Their problem is that, using the existing methods, they can't get more than ~1 M packets/s into their software.
I guess they are not using dedicated router hardware because there's no way to run their software on it. At which point, maybe they need a piece of kit based on Cavium's chips (lots of of low performance cores).
This isn't a step back for open source; it's just staying the same.
Despite the great success of open source software, which I'm using to write this post, the underlying computers where this software runs have always been proprietary hardware implementations with some proprietary firmware blobs (eg, the BIOS) stored somewhere.
The fact that some companies have moved from hardware to on-board firmware stored on EEPROMs to firmware which needs to be uploaded by the driver isn't a real change , as long as the license allows it to be freely redistributed. It is not an ideal situation; it would be better if this firmware was open source. But it's not anything new or different.
Unless the system has an I/O MMU, the hardware devices and any firmware they may be running have unrestricted access to RAM. I/O MMUs were almost exclusive to server chipsets until some time ago. Nowadays they are more common (spurred mostly by virtualization needs) but not totally universal yet. Intel likes to disable the feature in the K CPU models (which have unlocked frequency multipliers for better overclocking options). I don't keep track of the status of phone/tablet SoCs but if I had to hazzard a guess, I'd bet most of them don't have an I/O MMU.
For such a short post, you've got plenty of wrong things.
You assume that this is only about 3D. Now I don't know about Intel's plans but with the open source driver without the firmware blob, I can't even get my AMD card to work at more than 800x600. No mode settings (screen resolution), no power management, no video decoding, no accelerated anything: neither 3D nor 2D. Without the firmware blob, it's just an expensive power hungry 800x600 dumb frame buffer.
And there are _not_ plenty of cards out there. Intel, NVIDIA, AMD (and Matrox) are the only choices if you want to buy new hardware. With Matrox not being present in the laptop market. Intel was the last of the these which did not require a firmware blob.
x87 can produce IEEE 754 compliant results if the compiler either sets the correct rounding mode before each operation OR if it stores and reloads the results of each operation into memory (forcing the correct rounding). However, both are expensive to do, performance wise, and no compiler does so by default. Instead, x87 is normally used a way which is not IEEE 754 compliant, although it's actually a bit more accurate: internally, everything is done with 80 bit precision. This results from the fact the x87 unit actually predates the final version of the IEEE 754 standard.
The IEEE 754 standard only covers a few operations: add, subtract, multiply, divide, FMA, The transcendals (sin, cos, tag, exp, pow, etc) functions have never been part of the IEEE 754. Historically, most x87 FPUs have had errors larger than 1 ulp, at least for some part of the range.it If I am not mistaken, only the AMD K5 FPU actually provided errors of less than 1 ulp for the entire range of inputs. And please, take this with a large grain of salt.
The existing system (Pulse Code Cab Signaling) is quite limited in many ways. http://en.wikipedia.org/wiki/Pulse_code_cab_signaling
One of them is that it only offers a few speed limits, so often trains would have to run slower than otherwise needed. It also doesn't prevent all the cases PTC mandate requires.
I'm not sure if the combination of PCC wht ACSES (another system Amtrak has been deploying) meets the PTC mandate or not.
Ubuntu was already using their own init (upstart) since 2009 and they were not, understandably, motivated to drop it in favor of systemd. They only decided to move to systemd as Debian decided on systemd as the new default, instead of upstart.
Just upgraded my hobby server from Wheezy to Jessie. sysvinit was upgraded and remained as the init. The only bits of systemd in the system are the libsystemd* libraries.
Maybe you have a service which has some systemd dependency?
Primary radar (what you call search radar) is not very used for air traffic control. Primary radar stations are very expensive to build and to operate; their range and accuracy is rather limited too. That is because primary radar stations need to transmit very powerful pulses and listen back for the very faint echoes generated by the aircraft, while discerning them from all the other sources of noise and clutter. In general, only the military operate primary radar stations and coverage is rather limited. Eg, a large country like the USA will not have much coverage of primary radar deep inside it's borders. For poorer countries, even at the borders you may have nothing. Some countries (eg, USA, Russia, Australia) have long wave radar stations which can detect the launch of a missile or a bomber squadron half world away, but those provide very very rough information.
The current primary tool for air traffic control, being superseded by ADS-B, is secondary radar. In this type, the radar stations emit pulses which are detected by the transponders of (cooperative) aircraft. The transponders then transmit (sqwak) a reply to the radar pulse, which is detected by the radar station. This requires much less power to be transmitted by the radar station and the transponder reply is a much stronger signal than an echo. The transponder signal can also include information such as aircraft ID, altitude and etc.
1.5 Even among applications who heavily use server-side rendering, they tend to be more sensitive to network latency and bandwidth than midle-man solutions like NX and Xpra. When working remotely from home to work, no application I use behaves as well when using X forwarding as it does under Xpra. A few are completely useless with X forwaring. No application I can think of allows itself to be detached from a Xserver and attached to another one.
The usefulness of X11 network capabilities only works so far, dependind on the application, network latency and bandwidth and whether you need or not detach/reattach. For a lot of users of remote display, it's necessary use midle-man solutions like NX and Xpra, ignoring X11's network capabilities.
Ultimately, I cannot explain to you it's not possible; absence of a solution is not proof of it's non-existence. I can enumerate the known difficulties.
1. Fastest rendering method we have nowadays is direct rendering on the GPU hardware. Second fastest is often server side software rendering. X11 server side rendering often comes last. The issue with methods 1 and 2 is that they include the application sending large amounts of pixmaps to the display server (akin to playing video). Only effective use of method 3 makes X11's network capabilities useful.
But, when faced with the decision, application developers tend to favor 1 or 2 and ignore 3. History teaches us this: it was happening before the Xrender extension; it happened again now, as Qt5 does not have an effective server side rendering backend. Thus, making network capability a core part of the display system can be an exercise in futility, as application developers may simply not make use of it.
2. Server side rendering, which as I've shown is an integral part of X11's network capabilities, adds considerable complexity to the display server. This is an huge issue in Wayland. In Wayland, the display server, the window manager and the compositor are rolled-in into a single program, known as the Wayland compositor. To make this work, Wayland compositors must be relatively simple, not much more complicated than X11 window manager/compositors. This is not compatible with supporting the sophisticated server side rendering features provided by X11. The X.org display server is a huge program, in part because the X11 protocol is complex.
If you insist in asking the wrong question, you'll always get non-sense as an answer.
The server isn't being bloated with new button styles and widgets. X11 server side rendering is accomplished with a a relatively small number of power primitives which haven't been changed in years.
The reason why applications are doing less server side rendering, however, has to do with much more than fancy buttons and widgets. For example, the Qt4 folks came to the conclusion that their raster backend was quite a bit faster (for local applications, of course) than their X11 backend. This matters little for drawing the buttons and widgets of an application. But it does matter a lot for the main application area, specially when it's something a bit more complex than a text editor. It matters when you're navigating a PDF in Okular on a not-so-fast laptop. It matters when you're navigating through the mess of wires in an integrated circuit layout application.
For someone who chastises others for bell and whistles, you can't actually see under the surface.
Whether you are using "ssh -X" or just using DISPLAY to point your application to another machine, it is useful because of two properties in the X protocol, which Wayland does have.
Property 1: Although we routinely use shared memory extensions in modern X setups, a lot (including the core functions to which all applications must be able to fall back) works over a socket, which can be a unix local socket or a TCP socket. Property 2: The X11 protocol has a slew of very sophisticated features which enabled graphical applications to work around the latency of the communication and to reduce communication bandwidth. An application can store gylphs in the Xserver and then, referencing those gylphs, it can draw nice anti-aliased text using a very small amount of bandwidth.
Wayland lacks both properties, but property 2 is the big issue. Redirecting X11 applications over a network doesn't work well if the application sends a ton of commands synchronously, unless the network is low latency (eg, local LAN). Redirecting X11 applications over the network doesn't work well if the application sends the entire graphics window as a single pixmap, untless it's a high bandwith network (eg, local GbE LAN).
Wayland works over a Unix socket too. And you can set which socket the application will attach to with WAYLAND_DISPLAY. The first problem is that the protocol assumes shared memory but it would have not complicated things that much to make it work without requiring shared memory. But the real problem is that the only method Wayland applications have to draw is by sending the entire window (surface) as a single pixmap. Works wonderfully over shared memory, works like crap over my cell phone's 3G connection. A 800x600 surface rendered at 60 fps requires 86.4 MB/s.
Adding to Wayland the rich set of server-side rendering features would complicate things too much for Wayland to be possible. And it would be a somewhat futile exercise because, increasingly, X11 applications are doing less server side rendering and more pushing of large pixmaps.
99% of people don't want X11 style network transparency. They want "ssh -X" and friends to work. They want to be able to remotely run individual graphical applications. But X11-style network transparency isn't the only way. And it's not the best way.
Despite all the features available in X, application developers give limited effort to making applications work well over high latency limited bandwidth. An increasing number of applications work poorly over this links. Qt4 applications with the default raster backend work poorly sometimes even my workplace's GbE LAN (Qt5 doesn't even give you the option). Let's not even think of running Kate from home. No application I actually use supports detaching and re-attaching to a different X server.
People have been pushed to replace "ssh -X" with NX and Xpra (or, in despair, VNC) because of these limitations (Google about them). Similar solutions can be implemented in Wayland and they don't need the protocol to become networks transparent.
Supporting X11-style network transparency in the Wayland protocol is a futile exercise which compromises the simplicity required by the Wayland model.
Not to mention, if "ssh -X " and friends suits you... then it will work for a long time. As long as your Wayland session includes XWayland (which it will, probably for ever) and your applications retain a X11 backend, this will still work. It's not going to die tomorrow just because we switch to Wayland compositors.
As I wrote in the another post[1], you need to limit both lateral and vertical accelerations, which puts constrains on how much you can get from banking. Eg, if you bank almost 90, the passengers will experience no lateral acceleration, but they will experience vertical acceleration, for which tolerance is even lower. At 800 mph, even the sloping the line up/down will be a problem.
This is all well understood and researched, as it's a massive and expensive problem for all modes of transportation that go at least as fast as a car in a highway. The Hyperloop proposal simply glossed over reality in this aspect, along many others.
You can also tilt the track, canting in railway terms. Canting in normal railway lines is limited due to the need to handle slow trains, but on high speed rail it's often allowed to be higher. That's why it's uncommon to use tilting trains above 250 km/h: it's usually preferable to tilt the track than to increase the weight of trains by adding tilting systems. Though the Japanese have some.
That said, "much" is a relative statement, Whether you tilt the train floor or the track the accelerations experienced by the passenger - lateral: is v^2/r - g*sin(tilt_angle); acceptable limit is +/- 0.1g - vertical: 1g + v^2/r * cos(title_angle); limit is 1g+/-0.05g, IIRC
As you can seen from the math, the problem increases with the square of speed, while the benefit from tilt is is limited and bound by the need to keep both lateral and vertical acceleration within bounds.
The HyperLoop Elon proposed was estimated to cost 1/10th of the LA-SF CHSR project, but it only had 1/10th of the capacity.
Unlike the CHSR project, the proposed HyperLoop project actually only connected the outskirts of LA to the Oakland bay, leaving out the expensive part of going to downtown LA and downtown SF.
The estimated HyperLoop projects assumed they save on expropriations by placing the track elevated over existing highways. But to travel at 800 mph without making your passengers sick and barfing, the route actually needs curves to be 16 times as smooth as the 200 mph CHSR.
The estimated HyperLoop costs were low by an order of magnitude even when comparing to known costs of elevated track and even of oil pipelines. Let's not even talk about the actual precision needed to make this work at 800 mph.
What happened to HTTP/1.1 pipelining is fortunately not a common case: popular webserver breaks the standard and doesn't get fixed, making the standard de facto useless. While it's not impossible for the same to happen with HTTP/2.0, this type of situation is more the exception than the norm. All popular webservers today strive for a good degree of standard compliance.
But, maybe as importantly, as pointed out before, that was not the only problem with HTTP/1.1 pipelining. You also have the head of line blocking problem, which is a fundamental design problem. This reduced the case to enable HTTP/1.1 pipelining in the browsers and to fix the broken server software.
You might be happier if you researched why HTTP pipelining is off in most browsers and what problem it actually wants to solve.
First, HTTP/1.1 pipelining and HTTP/2.0 are not about increasing the number of request your server can handle. It's mainly about reducing the effect of round trip latency in page loading times, which is significant. If a browser is fetching a simple page with 10 tiny elements (or even cached elements subject to conditional GET) but the server round trip latency is 100 ms, then it will take over 1 second to load the page.
HTTP was a first attempt to solve this problem, by allowing the server to send multiple requests over the connection without waiting for the earlier requests to complete. If you can pipeline N requests, the round trip latency contribution is divided by N. However, HTTP/1.1 pipelining has two issues which led most browsers to disable it by default (it's not because they enjoy implementing features not be used): - There are or were a number of broken servers which do not handle pipelining correctly. - HTTP/1.1 pipelining is subject to head of line blocking: the server serves the requests in order and a small/fast request may have to wait inline behind a larger/slow request.
Instead, browsers make multiple parallel requests to each server. However, because some servers (eg, Apache) have problems with large numbers of requests so browsers use arbitrary low limits (eg, 4-8 parallel requests per hostname).
HTTP/2.0 attempts to solve these shortcomings by: a) being new, hopefully without broken servers out there b) using multiplexing, allowing the server to serve the requests in whatever order. Thus, no head-of-line blocking.
So. HTTP/2.0 is, fundamentally, HTTP/1.1 pipelining without these shortcomings. We hope.
Slashdot Mirror
Nowadays, tracks are usually inspected with track inspection vehicles, which are fitted with a number of sensors and can inspect tracks at speeds of up to 50 km per hour (last time I checked).
High speed rail tracks may be inspected several times per week, during the night.
I'm not aware of any practical maglev system which levitates by using magnetic repulsion against a simple sheet of metal (copper).
Depending on how much power they're using and whether they can make it work with a cheaper metal than copper, this can be an interesting technology.
Their goal is to receive the packets into their own user space analysis software and drop most of them (as being a flood attack).
Their problem is that, using the existing methods, they can't get more than ~1 M packets/s into their software.
I guess they are not using dedicated router hardware because there's no way to run their software on it.
At which point, maybe they need a piece of kit based on Cavium's chips (lots of of low performance cores).
A DC brush-less motor is nothing more than an AC synchronous motor with a variable voltage/variable frequency drive bolted onto the casing.
This isn't a step back for open source; it's just staying the same.
Despite the great success of open source software, which I'm using to write this post, the underlying computers where this software runs have always been proprietary hardware implementations with some proprietary firmware blobs (eg, the BIOS) stored somewhere.
The fact that some companies have moved from hardware to on-board firmware stored on EEPROMs to firmware which needs to be uploaded by the driver isn't a real change , as long as the license allows it to be freely redistributed.
It is not an ideal situation; it would be better if this firmware was open source. But it's not anything new or different.
Unless the system has an I/O MMU, the hardware devices and any firmware they may be running have unrestricted access to RAM.
I/O MMUs were almost exclusive to server chipsets until some time ago.
Nowadays they are more common (spurred mostly by virtualization needs) but not totally universal yet. Intel likes to disable the feature in the K CPU models (which have unlocked frequency multipliers for better overclocking options).
I don't keep track of the status of phone/tablet SoCs but if I had to hazzard a guess, I'd bet most of them don't have an I/O MMU.
For such a short post, you've got plenty of wrong things.
You assume that this is only about 3D.
Now I don't know about Intel's plans but with the open source driver without the firmware blob, I can't even get my AMD card to work at more than 800x600.
No mode settings (screen resolution), no power management, no video decoding, no accelerated anything: neither 3D nor 2D.
Without the firmware blob, it's just an expensive power hungry 800x600 dumb frame buffer.
And there are _not_ plenty of cards out there.
Intel, NVIDIA, AMD (and Matrox) are the only choices if you want to buy new hardware. With Matrox not being present in the laptop market.
Intel was the last of the these which did not require a firmware blob.
x87 can produce IEEE 754 compliant results if the compiler either sets the correct rounding mode before each operation OR if it stores and reloads the results of each operation into memory (forcing the correct rounding).
However, both are expensive to do, performance wise, and no compiler does so by default.
Instead, x87 is normally used a way which is not IEEE 754 compliant, although it's actually a bit more accurate: internally, everything is done with 80 bit precision.
This results from the fact the x87 unit actually predates the final version of the IEEE 754 standard.
The IEEE 754 standard only covers a few operations: add, subtract, multiply, divide, FMA,
The transcendals (sin, cos, tag, exp, pow, etc) functions have never been part of the IEEE 754. Historically, most x87 FPUs have had errors larger than 1 ulp, at least for some part of the range.it
If I am not mistaken, only the AMD K5 FPU actually provided errors of less than 1 ulp for the entire range of inputs. And please, take this with a large grain of salt.
The existing system (Pulse Code Cab Signaling) is quite limited in many ways.
http://en.wikipedia.org/wiki/Pulse_code_cab_signaling
One of them is that it only offers a few speed limits, so often trains would have to run slower than otherwise needed.
It also doesn't prevent all the cases PTC mandate requires.
I'm not sure if the combination of PCC wht ACSES (another system Amtrak has been deploying) meets the PTC mandate or not.
Ubuntu was already using their own init (upstart) since 2009 and they were not, understandably, motivated to drop it in favor of systemd.
They only decided to move to systemd as Debian decided on systemd as the new default, instead of upstart.
Just upgraded my hobby server from Wheezy to Jessie. sysvinit was upgraded and remained as the init.
The only bits of systemd in the system are the libsystemd* libraries.
Maybe you have a service which has some systemd dependency?
Primary radar (what you call search radar) is not very used for air traffic control.
Primary radar stations are very expensive to build and to operate; their range and accuracy is rather limited too. That is because primary radar stations need to transmit very powerful pulses and listen back for the very faint echoes generated by the aircraft, while discerning them from all the other sources of noise and clutter.
In general, only the military operate primary radar stations and coverage is rather limited. Eg, a large country like the USA will not have much coverage of primary radar deep inside it's borders. For poorer countries, even at the borders you may have nothing.
Some countries (eg, USA, Russia, Australia) have long wave radar stations which can detect the launch of a missile or a bomber squadron half world away, but those provide very very rough information.
The current primary tool for air traffic control, being superseded by ADS-B, is secondary radar.
In this type, the radar stations emit pulses which are detected by the transponders of (cooperative) aircraft. The transponders then transmit (sqwak) a reply to the radar pulse, which is detected by the radar station.
This requires much less power to be transmitted by the radar station and the transponder reply is a much stronger signal than an echo. The transponder signal can also include information such as aircraft ID, altitude and etc.
You've got your math wrong somehow.
1509 meter * 1260 kg * 9.8 m/s = 18 MJ = 5.2 kWh.
Sorry, I forgot to add a point 1.5.
1.5 Even among applications who heavily use server-side rendering, they tend to be more sensitive to network latency and bandwidth than midle-man solutions like NX and Xpra.
When working remotely from home to work, no application I use behaves as well when using X forwarding as it does under Xpra. A few are completely useless with X forwaring.
No application I can think of allows itself to be detached from a Xserver and attached to another one.
The usefulness of X11 network capabilities only works so far, dependind on the application, network latency and bandwidth and whether you need or not detach/reattach.
For a lot of users of remote display, it's necessary use midle-man solutions like NX and Xpra, ignoring X11's network capabilities.
Ultimately, I cannot explain to you it's not possible; absence of a solution is not proof of it's non-existence.
I can enumerate the known difficulties.
1. Fastest rendering method we have nowadays is direct rendering on the GPU hardware. Second fastest is often server side software rendering. X11 server side rendering often comes last.
The issue with methods 1 and 2 is that they include the application sending large amounts of pixmaps to the display server (akin to playing video).
Only effective use of method 3 makes X11's network capabilities useful.
But, when faced with the decision, application developers tend to favor 1 or 2 and ignore 3.
History teaches us this: it was happening before the Xrender extension; it happened again now, as Qt5 does not have an effective server side rendering backend.
Thus, making network capability a core part of the display system can be an exercise in futility, as application developers may simply not make use of it.
2. Server side rendering, which as I've shown is an integral part of X11's network capabilities, adds considerable complexity to the display server.
This is an huge issue in Wayland. In Wayland, the display server, the window manager and the compositor are rolled-in into a single program, known as the Wayland compositor.
To make this work, Wayland compositors must be relatively simple, not much more complicated than X11 window manager/compositors.
This is not compatible with supporting the sophisticated server side rendering features provided by X11. The X.org display server is a huge program, in part because the X11 protocol is complex.
If you insist in asking the wrong question, you'll always get non-sense as an answer.
The server isn't being bloated with new button styles and widgets. X11 server side rendering is accomplished with a a relatively small number of power primitives which haven't been changed in years.
The reason why applications are doing less server side rendering, however, has to do with much more than fancy buttons and widgets.
For example, the Qt4 folks came to the conclusion that their raster backend was quite a bit faster (for local applications, of course) than their X11 backend.
This matters little for drawing the buttons and widgets of an application. But it does matter a lot for the main application area, specially when it's something a bit more complex than a text editor.
It matters when you're navigating a PDF in Okular on a not-so-fast laptop. It matters when you're navigating through the mess of wires in an integrated circuit layout application.
For someone who chastises others for bell and whistles, you can't actually see under the surface.
should read "which Wayland does _NOT_ have"
True, it's not about network access per se.
Whether you are using "ssh -X" or just using DISPLAY to point your application to another machine, it is useful because of two properties in the X protocol, which Wayland does have.
Property 1: Although we routinely use shared memory extensions in modern X setups, a lot (including the core functions to which all applications must be able to fall back) works over a socket, which can be a unix local socket or a TCP socket.
Property 2: The X11 protocol has a slew of very sophisticated features which enabled graphical applications to work around the latency of the communication and to reduce communication bandwidth. An application can store gylphs in the Xserver and then, referencing those gylphs, it can draw nice anti-aliased text using a very small amount of bandwidth.
Wayland lacks both properties, but property 2 is the big issue.
Redirecting X11 applications over a network doesn't work well if the application sends a ton of commands synchronously, unless the network is low latency (eg, local LAN).
Redirecting X11 applications over the network doesn't work well if the application sends the entire graphics window as a single pixmap, untless it's a high bandwith network (eg, local GbE LAN).
Wayland works over a Unix socket too. And you can set which socket the application will attach to with WAYLAND_DISPLAY.
The first problem is that the protocol assumes shared memory but it would have not complicated things that much to make it work without requiring shared memory.
But the real problem is that the only method Wayland applications have to draw is by sending the entire window (surface) as a single pixmap. Works wonderfully over shared memory, works like crap over my cell phone's 3G connection.
A 800x600 surface rendered at 60 fps requires 86.4 MB/s.
Adding to Wayland the rich set of server-side rendering features would complicate things too much for Wayland to be possible.
And it would be a somewhat futile exercise because, increasingly, X11 applications are doing less server side rendering and more pushing of large pixmaps.
99% of people don't want X11 style network transparency. They want "ssh -X" and friends to work. They want to be able to remotely run individual graphical applications.
But X11-style network transparency isn't the only way. And it's not the best way.
Despite all the features available in X, application developers give limited effort to making applications work well over high latency limited bandwidth. An increasing number of applications work poorly over this links. Qt4 applications with the default raster backend work poorly sometimes even my workplace's GbE LAN (Qt5 doesn't even give you the option). Let's not even think of running Kate from home.
No application I actually use supports detaching and re-attaching to a different X server.
People have been pushed to replace "ssh -X" with NX and Xpra (or, in despair, VNC) because of these limitations (Google about them).
Similar solutions can be implemented in Wayland and they don't need the protocol to become networks transparent.
Supporting X11-style network transparency in the Wayland protocol is a futile exercise which compromises the simplicity required by the Wayland model.
Not to mention, if "ssh -X " and friends suits you... then it will work for a long time. As long as your Wayland session includes XWayland (which it will, probably for ever) and your applications retain a X11 backend, this will still work.
It's not going to die tomorrow just because we switch to Wayland compositors.
As I wrote in the another post[1], you need to limit both lateral and vertical accelerations, which puts constrains on how much you can get from banking.
Eg, if you bank almost 90, the passengers will experience no lateral acceleration, but they will experience vertical acceleration, for which tolerance is even lower.
At 800 mph, even the sloping the line up/down will be a problem.
This is all well understood and researched, as it's a massive and expensive problem for all modes of transportation that go at least as fast as a car in a highway.
The Hyperloop proposal simply glossed over reality in this aspect, along many others.
[1] http://tech.slashdot.org/comments.pl?sid=7030445&cid=49155263
You can also tilt the track, canting in railway terms.
Canting in normal railway lines is limited due to the need to handle slow trains, but on high speed rail it's often allowed to be higher.
That's why it's uncommon to use tilting trains above 250 km/h: it's usually preferable to tilt the track than to increase the weight of trains by adding tilting systems.
Though the Japanese have some.
That said, "much" is a relative statement, Whether you tilt the train floor or the track the accelerations experienced by the passenger
- lateral: is v^2/r - g*sin(tilt_angle); acceptable limit is +/- 0.1g
- vertical: 1g + v^2/r * cos(title_angle); limit is 1g+/-0.05g, IIRC
As you can seen from the math, the problem increases with the square of speed, while the benefit from tilt is is limited and bound by the need to keep both lateral and vertical acceleration within bounds.
The HyperLoop Elon proposed was estimated to cost 1/10th of the LA-SF CHSR project, but it only had 1/10th of the capacity.
Unlike the CHSR project, the proposed HyperLoop project actually only connected the outskirts of LA to the Oakland bay, leaving out the expensive part of going to downtown LA and downtown SF.
The estimated HyperLoop projects assumed they save on expropriations by placing the track elevated over existing highways.
But to travel at 800 mph without making your passengers sick and barfing, the route actually needs curves to be 16 times as smooth as the 200 mph CHSR.
The estimated HyperLoop costs were low by an order of magnitude even when comparing to known costs of elevated track and even of oil pipelines. Let's not even talk about the actual precision needed to make this work at 800 mph.
Note that server push applies to content the browser could request _from the same server_.
Usually ad content is served from third party servers.
But ultimately yes, this can lead to wasting some of your bandwidth in content your browser would have otherwise not asked.
What happened to HTTP/1.1 pipelining is fortunately not a common case: popular webserver breaks the standard and doesn't get fixed, making the standard de facto useless. While it's not impossible for the same to happen with HTTP/2.0, this type of situation is more the exception than the norm.
All popular webservers today strive for a good degree of standard compliance.
But, maybe as importantly, as pointed out before, that was not the only problem with HTTP/1.1 pipelining. You also have the head of line blocking problem, which is a fundamental design problem.
This reduced the case to enable HTTP/1.1 pipelining in the browsers and to fix the broken server software.
You might be happier if you researched why HTTP pipelining is off in most browsers and what problem it actually wants to solve.
First, HTTP/1.1 pipelining and HTTP/2.0 are not about increasing the number of request your server can handle. It's mainly about reducing the effect of round trip latency in page loading times, which is significant.
If a browser is fetching a simple page with 10 tiny elements (or even cached elements subject to conditional GET) but the server round trip latency is 100 ms, then it will take over 1 second to load the page.
HTTP was a first attempt to solve this problem, by allowing the server to send multiple requests over the connection without waiting for the earlier requests to complete.
If you can pipeline N requests, the round trip latency contribution is divided by N.
However, HTTP/1.1 pipelining has two issues which led most browsers to disable it by default (it's not because they enjoy implementing features not be used):
- There are or were a number of broken servers which do not handle pipelining correctly.
- HTTP/1.1 pipelining is subject to head of line blocking: the server serves the requests in order and a small/fast request may have to wait inline behind a larger/slow request.
Instead, browsers make multiple parallel requests to each server.
However, because some servers (eg, Apache) have problems with large numbers of requests so browsers use arbitrary low limits (eg, 4-8 parallel requests per hostname).
HTTP/2.0 attempts to solve these shortcomings by:
a) being new, hopefully without broken servers out there
b) using multiplexing, allowing the server to serve the requests in whatever order. Thus, no head-of-line blocking.
So. HTTP/2.0 is, fundamentally, HTTP/1.1 pipelining without these shortcomings. We hope.