More than a few thousand rules. Something that would enable you to actually route particular traffic to particular destinations and back. Something that isn't just a nifty configuration interface to private VLANs.
A few million rules would be great, then you could actually make use of the MPLS tag support. A few hundred thousand would enable multiple rules per VM in a cloud setup. Less than 10000 is just too cramped unless you just use it to make VM migration easy.
The F1 tires have lousy grip at low temperatures. Give them a set of tires optimized for low speed plus traction control and ESP to keep the engine from using up all the grip, and they will steer just fine at low speeds.
I have never actually driven an original Mini myself, but it felt quite like a go-cart to me as a passenger. It did not seem to have any obvious handling problems despite some rather spirited driving.
I have driven an Open Corsa (Vauxhall Nova?) original version quite a lot, and that is not much heavier. Handling was subjectively better than any other Opel I have tried before or after -- it was quite a bit of fun. Acceleration was non-existent, of course, so maintaining speed through corners was imperative.
Friction scales almost linearly with mass. If you add mass, you get more friction, but you have more mass you need to accelerate, so you have not gained or lost anything.
Also, look up how much the original Mini Cooper weighed. Almost exactly the same as an Atom.
That doesn't mean you want to waste a lot of energy generating non-recyclable carbon fiber products that will fill up landfills.
It only takes up space in landfills if you fail to incinerate it. You need a proper incineration plant to avoid generating toxic smoke, but that is rather old technology at this point, and you get useful heat out of the process.
The only devices that actually support a useful amount of SDN rules are expensive routers like the Juniper MX series. As long as that is the case, SDN will be limited to doing things that you could do already with a bit more configuration on existing switches. Nice, but not ground-shaking.
SDN will only truly break new ground when someone releases a more flexible switch chip at an affordable price.
Communications are likely to be point-to-point, and we only get to catch the signal if it randomly points at us for a moment.
We emit lots of radar, and we could be easily detected that way, but military radar is going spread-spectrum or passive and civilian radar is relying more and more on active transponders. If we fixed our light pollution as well, intelligent life on Earth would be quite well hidden.
Only because Turing machines have infinite memories, and therefore no actual Turing machines exist. Given an actual Turing machine and a bit of patience, you can solve halting for all physically existing machines.
Intuitively you would expect the difficulty of solving the halting problem to be exponential to the size of the storage of the computer you are trying to solve halting for, but I am not sure whether that has been proven.
What this means is that filesystems associated with booting (root, swap, dev,...) are now systemd entries instead of/etc/fstab entries.
What would have been lost by adding them to/etc/fstab? That way you would be able to tell systemd not to mount them, if need be, or to mount them elsewhere.
standardized, indexed way within its own file.
Said standard being the systemd source code of the day. No external tools can handle the format. journalctl performance is a complete joke, and that is in comparison to full-text grep of the text files -- quite an accomplishment actually.
"Note that the actual implementation in the systemd codebase is the only ultimately authoritative description of the format, so if this document and the code disagree, the code is right."
You cannot really make a system that consists of a bunch of shell scripts and have it work for a modern laptop where devices and network connections come and go, and you really want different things to run depending on whether you are at home or on the unencrypted airport wifi.
SysV init needed replacing. It is just unfortunate that the replacement is systemd.
Anyway, I should really stop complaining about systemd, I gave up Linux on the laptop last year and now I am on OS X.
The configuration system for daemons that systemd has is an enormous leap forward over the old shell scripts. If systemd would stick to be an init system, it would not be such a problem.
When it takes over file system mounting, including hiding most mount points from/etc/fstab and breaking silently if there are perfectly valid mounts in there which it happens not to like, people complain.
When it takes over system logging, previously one of the major advantages of Unix-based systems over Windows, people complain.
Do I really need to know that, or can I just switch to a different thread of execution until then?
Sun tried it, market penetration near zero. You can get 12 threads per socket on a desktop Intel CPU, good luck keeping 12 threads busy on mainstream workloads.
Single threaded performance is everything for a CPU; it is cheap to add sockets and cores for parallel workloads. For real parallel work you use the GPU anyway.
You cannot meaningfully do reordering and so on in software on a modern CPU. You do not know in advance which operands will be available from memory at which time. You have to redo that work every time you get to the code (unless it is in a tight loop, but modern x86's are REALLY good at tight loops) because circumstances will likely have changed -- and you cannot reorder in software every time, that is just too costly.
If you want to see an architecture which looks like it has a chance of breaking the limits on single-threaded performance, look at the Mill. In theory you could software-translate x86 to Mill code and gain performance, but it would be really tricky and no Mill implementations exist yet.
Transmeta was at the end of the era where decoding performance mattered. Keeping the translated code around was actually useful. These days decoding is approximately free on any CPU with half-decent performance -- the amount of extra die space for a complex decoder is not worth worrying about.
You can save a bit of power with a simpler decode stage, but you are unlikely to beat ARM Thumb-2 on power by software-translating x86 the way Transmeta did. Besides, most of the interesting code for low power applications is ARM or MIPS already, so what is the point?
Netflix offers to bring the bandwidth to the ISP for free, with their content boxes. They will happily deliver their content directly to the ISP. But free was not good enough for Verizon.
Just be aware that some of the efficiency of pedal bikes is due to their low speed. If you limit the Scion to 20MPH, it is going to gain a lot of efficiency.
Nevertheless a diesel-electric engine/train is more efficient than a pure diesel.
A diesel-electric power train actually exists and works, so in that way it is certainly more efficient than a non-existent pure diesel power train.
Diesel passenger trains often go with a lorry-like engine with mechanical gears; with one (or multiple) engines per wagon they do not need so much low-end torque for each engine and they can avoid the wasteful electric drive train.
Hopefully diesel will go away for trains soon as more and more track is electrified.
They are just regular crappy diesel engines plus an inefficient electrical power train. Efficiency is not particularly a concern for freight trains; fuel is a small part of the operating expenses.
Slashdot Mirror
More than a few thousand rules. Something that would enable you to actually route particular traffic to particular destinations and back. Something that isn't just a nifty configuration interface to private VLANs.
A few million rules would be great, then you could actually make use of the MPLS tag support. A few hundred thousand would enable multiple rules per VM in a cloud setup. Less than 10000 is just too cramped unless you just use it to make VM migration easy.
The F1 tires have lousy grip at low temperatures. Give them a set of tires optimized for low speed plus traction control and ESP to keep the engine from using up all the grip, and they will steer just fine at low speeds.
I have never actually driven an original Mini myself, but it felt quite like a go-cart to me as a passenger. It did not seem to have any obvious handling problems despite some rather spirited driving.
I have driven an Open Corsa (Vauxhall Nova?) original version quite a lot, and that is not much heavier. Handling was subjectively better than any other Opel I have tried before or after -- it was quite a bit of fun. Acceleration was non-existent, of course, so maintaining speed through corners was imperative.
Friction scales almost linearly with mass. If you add mass, you get more friction, but you have more mass you need to accelerate, so you have not gained or lost anything.
Also, look up how much the original Mini Cooper weighed. Almost exactly the same as an Atom.
That doesn't mean you want to waste a lot of energy generating non-recyclable carbon fiber products that will fill up landfills.
It only takes up space in landfills if you fail to incinerate it. You need a proper incineration plant to avoid generating toxic smoke, but that is rather old technology at this point, and you get useful heat out of the process.
It's carbon, surely it burns?
I don't see a problem with turning coal into a useful product before it gets burned for electricity.
The only devices that actually support a useful amount of SDN rules are expensive routers like the Juniper MX series. As long as that is the case, SDN will be limited to doing things that you could do already with a bit more configuration on existing switches. Nice, but not ground-shaking.
SDN will only truly break new ground when someone releases a more flexible switch chip at an affordable price.
Communications are likely to be point-to-point, and we only get to catch the signal if it randomly points at us for a moment.
We emit lots of radar, and we could be easily detected that way, but military radar is going spread-spectrum or passive and civilian radar is relying more and more on active transponders. If we fixed our light pollution as well, intelligent life on Earth would be quite well hidden.
Only because Turing machines have infinite memories, and therefore no actual Turing machines exist. Given an actual Turing machine and a bit of patience, you can solve halting for all physically existing machines.
Intuitively you would expect the difficulty of solving the halting problem to be exponential to the size of the storage of the computer you are trying to solve halting for, but I am not sure whether that has been proven.
Your phone number is digital. When you recall it, you know it is precisely right, and so your memory of it gets re-saved, error-corrected.
Most things you want to remember are not digital.
What this means is that filesystems associated with booting (root, swap, dev, ...) are now systemd entries instead of /etc/fstab entries.
What would have been lost by adding them to /etc/fstab? That way you would be able to tell systemd not to mount them, if need be, or to mount them elsewhere.
standardized, indexed way within its own file.
Said standard being the systemd source code of the day. No external tools can handle the format. journalctl performance is a complete joke, and that is in comparison to full-text grep of the text files -- quite an accomplishment actually.
"Note that the actual implementation in the systemd codebase is the only ultimately authoritative description of the format, so if this document and the code disagree, the code is right."
You cannot really make a system that consists of a bunch of shell scripts and have it work for a modern laptop where devices and network connections come and go, and you really want different things to run depending on whether you are at home or on the unencrypted airport wifi.
SysV init needed replacing. It is just unfortunate that the replacement is systemd.
Anyway, I should really stop complaining about systemd, I gave up Linux on the laptop last year and now I am on OS X.
systemd does FAR more than just boot. If it went away after boot, few would complain, but it would lose most of its reason to exist.
The configuration system for daemons that systemd has is an enormous leap forward over the old shell scripts. If systemd would stick to be an init system, it would not be such a problem.
When it takes over file system mounting, including hiding most mount points from /etc/fstab and breaking silently if there are perfectly valid mounts in there which it happens not to like, people complain.
When it takes over system logging, previously one of the major advantages of Unix-based systems over Windows, people complain.
And so on and so forth.
Denmark, every time. As long as e-voting can be prevented despite the efforts of Trine Bramsen and other subversive forces.
Do I really need to know that, or can I just switch to a different thread of execution until then?
Sun tried it, market penetration near zero. You can get 12 threads per socket on a desktop Intel CPU, good luck keeping 12 threads busy on mainstream workloads.
Single threaded performance is everything for a CPU; it is cheap to add sockets and cores for parallel workloads. For real parallel work you use the GPU anyway.
Fair enough, but they still choose to have all decoding done in hardware, so they still pay the (rather small) die-space penalty of a complex decoder.
You cannot meaningfully do reordering and so on in software on a modern CPU. You do not know in advance which operands will be available from memory at which time. You have to redo that work every time you get to the code (unless it is in a tight loop, but modern x86's are REALLY good at tight loops) because circumstances will likely have changed -- and you cannot reorder in software every time, that is just too costly.
If you want to see an architecture which looks like it has a chance of breaking the limits on single-threaded performance, look at the Mill. In theory you could software-translate x86 to Mill code and gain performance, but it would be really tricky and no Mill implementations exist yet.
Transmeta was at the end of the era where decoding performance mattered. Keeping the translated code around was actually useful. These days decoding is approximately free on any CPU with half-decent performance -- the amount of extra die space for a complex decoder is not worth worrying about.
You can save a bit of power with a simpler decode stage, but you are unlikely to beat ARM Thumb-2 on power by software-translating x86 the way Transmeta did. Besides, most of the interesting code for low power applications is ARM or MIPS already, so what is the point?
What makes you think the fast lane does not exist? Netflix paid to avoid the 50% packet drop tax that Verizon inflicted on their traffic.
Netflix offers to bring the bandwidth to the ISP for free, with their content boxes. They will happily deliver their content directly to the ISP. But free was not good enough for Verizon.
Netflix bought the fast lane. What do you suppose a would-be Netflix competitor should do, serve streams with 50% packet loss to Verizon customers?
The whole summary and article is about why exactly that is insufficient.
Just be aware that some of the efficiency of pedal bikes is due to their low speed. If you limit the Scion to 20MPH, it is going to gain a lot of efficiency.
Nevertheless a diesel-electric engine/train is more efficient than a pure diesel.
A diesel-electric power train actually exists and works, so in that way it is certainly more efficient than a non-existent pure diesel power train.
Diesel passenger trains often go with a lorry-like engine with mechanical gears; with one (or multiple) engines per wagon they do not need so much low-end torque for each engine and they can avoid the wasteful electric drive train.
Hopefully diesel will go away for trains soon as more and more track is electrified.
They are just regular crappy diesel engines plus an inefficient electrical power train. Efficiency is not particularly a concern for freight trains; fuel is a small part of the operating expenses.