For one, I don't believe Windows was originally designed to be a multi-user OS, was it? Everything it does that pretends to be has been an afterthought kludge. I honestly don't know if this is the case with NT-based systems so feel free to correct me.
Wrong. NT was very much designed around a multi-user model, they just did not enable any multi-user interfaces beyond telnet. The same multi-user NT level separation and code running today was in the first NT release.
3rd parties were providing multi-user on NT back in 1992-1993 when it first shipped.
NT 4.0 added in RDP, but the multi-user model and concurrent multi-user access was already there, it was just the GUI protocol added.
OK, thanks for the explanations. So it comes down to the fact that there are different levels of interoperability, and.NET in combination with the CTS and IDynamicObject supports what's realistically possible, and it does that on a higher level than the traditional use of C for the same purpose.
The dynamic classes of Ruby, JavaScript, PHP etc. are accomodated by using the IDynamicObject interface.
You do not need to map dynamic classes to static classes. You would only need that if you wanted to be able to specialize classes from other languages. Most interoperability between languages will not require class interop. The most important interop needed is object interop, where you pass object instances between languages
Doesn't that just prove what I said? You *can't* represent mixin inheritance or the absence of side effects (which IDynamicObject doesn't even deal with) in a C#/Java-like language which has single inheritance only and side effects. Don't get me wrong -- it's nice that there's something like IDynamicObject that serves as a kind of standardized interoperability "bus", enabling a range of different languages to call each other more easily. But that's not in any way a perfect integration. Is it possible to mix Ruby mixins into C# classes? Probably not. And classless languages will have a hard time integrating automatically with.NET technologies like XAML that work by looking up classes by name and instantiating them all the time.
As a result, I'd expect that e.g. Ruby/C# interoperability in a.NET project won't be handled so much differently from how Ruby/C interoperability is handled in non-.NET projects: One language is used for low-level stuff, the other one for high-level integration or "glue code" (IDynamicObject might well make this usage pattern easier than it used to be). It would still be infeasible to support a scenario in which every developer, no matter what layer he's working on, just writes code in whatever language he or she prefers, and the runtime makes it all work together magically.
The latest development in.NET is to incorporate support for dynamic languages into.NET. C# 4.0 and the CTS will lay out a common principle (a "dynamic" interface) which theoretically can accommodate most known static languages, hybrid languages and dynamic languages on a very high level.
This will enable any language which adhere to this specification to participate in a high fidelity hub-and-spoke architecture. You will essentially be able to pass a IronRuby object to IronPython, C#, VB, F#, Eiffel etc. and interact with it there while still relying on the Ruby member resolution principles.
Really. So how are you going to represent classes with multiple or "mixin" inheritance in a language that only has static single inheritance? Or how are you going to map classic objects with modifiable state to stateless, side-effect-free languages like Haskell? I'd imagine that that's not going to be pretty, no matter what the underlying runtime can supposedly do, because the unpretty-ness is a function of the semantic gap between the languages themselves, not of some feature set (or lack thereof) in the runtime.
This is just more proof that the EU has a talent for demanding irrelevant stuff. If they must force companies to come up with a standard, then why not one for mechanical and electrical dimensions of laptop batteries? Rechargeable high-power batteries are real high-tech wear parts, so opening the market there and enabling battery manufacturers to sell their stuff directly to end users might actually stimulate competition and lower prices, right?
The only ways I can think of to "exhaust" (i.e. permanently destroy) a stable chemical like platinum element would be either putting it into a particle accelerator and splitting the atomic nuclei with something like fast neutrons, or shooting it into space. Everything we do it it in a fuel cell is chemistry (electron hull physics). We may have to recycle it from used cells (which might require energy), but it's not "exhausted".
What "impending end of the manned space program"? Is anyone intending to end it? Have I missed something? They just want to switch to a different vehicle, with a few years of no manned flights in between. There were no manned US flights between the last Apollo mission (1975) and the first STS mission (1981) either, so it's not as if this would be something entirely new. So what exactly is the author arguing for/against here? Continuing the Shuttle program indefinitely? Or until Ares is available?
The authors of the second amendment might have used a very similar argument to point out that a law that was made with 18th-century rifles in mind which take 1 minute to reload does not apply to fully automatic high-powered assault rifles that allow you to kill dozens of people around you before anyone could intervene.
With but one huge, glaring, ominous difference: solid-fueled rockets cannot be switched off or throttled once ignited,
Sure.
unlike liquid-fueled or solid/liquid hybrid designs. So, while solid boosters are simpler, they preclude any kind of escape system while they are firing.
How so? What you say is true for the Shuttle, but not necessarily for a more conventional booster with an Apollo/Soyuz-like launch escape system (LES). And this is exactly what's planned for Ares I: A single solid rocket for the first stage, and an LES. The LES should provide enough thrust to be able to pull the crew compartment away from almost any kind of event that happens to the launcher, including a failure of the booster. The fact that the shuttle system doesn't have a LES is orthogonal to the fact that the shuttle system uses solid rockets. The first fact is a serious flaw, the second not so much. The Shuttle SRBs have proved to be very reliable, with over 200 succesfully flown, and only one failure: The left SRB in the Challenger accident. That failure is now well understood and its cause has been eliminated. This means that the SRBs are very reliable, even more so if you take into account that the Shuttle SRB is by far the most powerful single rocket engine ever built, and that includes the Saturn V first stage engine. And as I said, a LES would probably have saved the Challenger crew.
But they apparently haven't learned that multiple liquid-fuelled engines with one-engine-out capability are safer than solid-fuel rockets.
I don't think there's any hard data to support that allegation. Solid-fuel rockets are much simpler and thus more reliable (in general), albeit less efficient, than liquid-fuelled rockets, which makes them good candidates for the first stage. Which is where the shuttle and the proposed new system (Constellation/Ares I) uses them. The "one-engine out" capability of the shuttle isn't fully available at all times -- if the engine fails early, the shuttle must immediately return to the launch site, which is an extremely risky (and never tried) maneuver that isn't necessary with an emergency escape system as Apollo and Soyuz (and the planned Ares I) have it. Such a system was successfully used several times, and it would probably have saved the lives of the Challenger crew.
The numbers are basically correct (the "your blood boils and you die within seconds" stuff is not). Pilots use the term "useful consciousness" to describe the timespan between rapid decompression of the plane and the time at which you can no longer perform basic tasks (like putting on your oxygen mask). At 11,000 meters, this time is down to something like 20 seconds. Which is the reason why oxygen masks are automatically deployed in such a case -- there just wouldn't be enough time to manually obtain them from a storage tank or something like that.
The way patents work is even if all of us 6.7 million run to the patent office, because we all had the same idea, the first would still get it (or Edison if he were still alive).
Well, if the law doesn't spare the "2nd" inventor the need to pay the patent license, I'd say fuck the patent system. The patent system was introduced so original inventors were encouraged to publicize their invention in an orderly fashion, enabling others (the licensees) to build upon that and achieve quicker innovation cycles themselves, while the original inventor also benefits because he gets to collect the license fees. In the end, the overall rate of innovation would increase and society as a whole should be better off than it would be if there was no patent system.
However, if a second original inventor reaches the same innovation independently, he hasn't benefited from then patent system and thus shouldn't have to pay license fees. If he is still forced to pay them, the patent system has been turned on its head because it is now stifling innovations rather than encouraging them, and it would have been better if there was no patent system in the first place.
The point is that NAT and security are completely orthogonal things. The "security features" of NAT are an "en passant" effect that results from the way NAT achieves what it is designed to achieve (hide multiple hosts behind one IP address). You don't need NAT in order to have those security features. They are equivalent to the security features of a network of hosts with all global IP addresses in which the "NAT router" is replaced with a stateful packet filter that rejects all packets except ones that initiate TCP connections from the inside to the outside, or belong to such connections. NAT exists to solve one, and only one, specific problem: You want to provide (some) internet access for more devices than you have public IP addresses. If you no longer have that problem, you don't need NAT anymore. Period. No exceptions.
If you destabilise one floor there is nowhere near enough energy to collapse the whole building when the rest of it is still largely intact.
So you mean the twin towers were also brought down by secret explosives on each floor, detonated with millisecond precision? I guess that makes total sense, especially if you ignore Ockham's razor and common sense passionately enough. And don't even mention the fact that WTC 7 wasn't "largely intact" except for one floor -- it had been evacuated half an hour before the collapse because the building was cracking and quivering so much that the question wasn't if it would collapse, but when. After that, they only thought about how large the evacuated collapse zone around the building would have to be to avoid further loss of life, for god's sake.
And, if the part of the building above that floor falls one floor deep and crashes onto the lower part, what force do you think that lower part would have to endure to avoid collapsing? Hint: F = weight + F_dynamic = m*g + dp/dt = m (g+deceleration). Depending on what you assume for the deceleration distance, that gives something like 10 times the weight of the upper part -- I wouldn't be surprised if the lower part wasn't designed to withstand that.
Anyway, the most obvious proof that a building can collapse straight down under its own weight even if the lower floors are intact is the fact that we saw it happen on 9/11. Period.
It's been a while. I used the 3D stuff, including solid modelling (i.e. the AME package). No 2D constructions or mechanical drawing; I didn't earn money with it or anything (I was still at school back then). I used R12 for DOS and later R14 for Windows, and I didn't find the difference between those two all that great. The GUI wasn't very sophisticated or anything, and it was kind of bolted-on (which I actually liked), but I still found it essential for, well, graphical previewing and interactive point selection (mostly the snapping features mentioned earlier). Let's say I wouldn't have use the program for very long if either the command line or the GUI had been missing.
Wow, now he wants to re-implement the Gnome Panel, file manager and Evolution in Moonlight. Has he finished implementing them in Mono already? This is kinda funny -- every time Microsoft comes up with some new technology, Miguel scrambles to write a clone of it, then goes on to re-implement Gnome in that. Reimplementing stuff is so much fun anyway! If MS wants to halt all actual progress in Gnome, all have to do is churn out new hype technologies every 12 months or so.
Remember that Lisp-y language with the turtle for drawing? Completely text based, interactive drawing.
You can also write javascript, microsoft shell script, and a few other languages to control/use photoshop.
Yeah. Sure you can. Please come back if professional designers or artists create their drawings using Logo or Javascript exclusively. You may not be an artist, but other people are:-P
Slashdot Mirror
Ok, let's get this one out of the way...
For one, I don't believe Windows was originally designed to be a multi-user OS, was it? Everything it does that pretends to be has been an afterthought kludge. I honestly don't know if this is the case with NT-based systems so feel free to correct me.
Wrong. NT was very much designed around a multi-user model, they just did not enable any multi-user interfaces beyond telnet. The same multi-user NT level separation and code running today was in the first NT release.
3rd parties were providing multi-user on NT back in 1992-1993 when it first shipped.
NT 4.0 added in RDP, but the multi-user model and concurrent multi-user access was already there, it was just the GUI protocol added.
Wrong -- they didn't just have to introduce the RDP protocol, they had to change the kernel to support multiple Windows sessions on the server side (the terminal services). The Win32 subsystem only supports one interactive user at a time, so the kernel had to be modified to run several such subsystems at a time. in contrast to that, "Since UNIX was developed from the beginning as a multi-user system, it has been optimized to run multiple sessions on a single server.". Straight from the horse's mouth.
According to the MSDN, the respective API calls have been introduces in Windows 2000. So it's not *that* old I figure.
OK, thanks for the explanations. So it comes down to the fact that there are different levels of interoperability, and .NET in combination with the CTS and IDynamicObject supports what's realistically possible, and it does that on a higher level than the traditional use of C for the same purpose.
The dynamic classes of Ruby, JavaScript, PHP etc. are accomodated by using the IDynamicObject interface.
You do not need to map dynamic classes to static classes. You would only need that if you wanted to be able to specialize classes from other languages. Most interoperability between languages will not require class interop. The most important interop needed is object interop, where you pass object instances between languages
Doesn't that just prove what I said? You *can't* represent mixin inheritance or the absence of side effects (which IDynamicObject doesn't even deal with) in a C#/Java-like language which has single inheritance only and side effects. Don't get me wrong -- it's nice that there's something like IDynamicObject that serves as a kind of standardized interoperability "bus", enabling a range of different languages to call each other more easily. But that's not in any way a perfect integration. Is it possible to mix Ruby mixins into C# classes? Probably not. And classless languages will have a hard time integrating automatically with .NET technologies like XAML that work by looking up classes by name and instantiating them all the time.
As a result, I'd expect that e.g. Ruby/C# interoperability in a .NET project won't be handled so much differently from how Ruby/C interoperability is handled in non-.NET projects: One language is used for low-level stuff, the other one for high-level integration or "glue code" (IDynamicObject might well make this usage pattern easier than it used to be). It would still be infeasible to support a scenario in which every developer, no matter what layer he's working on, just writes code in whatever language he or she prefers, and the runtime makes it all work together magically.
The latest development in .NET is to incorporate support for dynamic languages into .NET. C# 4.0 and the CTS will lay out a common principle (a "dynamic" interface) which theoretically can accommodate most known static languages, hybrid languages and dynamic languages on a very high level.
This will enable any language which adhere to this specification to participate in a high fidelity hub-and-spoke architecture. You will essentially be able to pass a IronRuby object to IronPython, C#, VB, F#, Eiffel etc. and interact with it there while still relying on the Ruby member resolution principles.
Really. So how are you going to represent classes with multiple or "mixin" inheritance in a language that only has static single inheritance? Or how are you going to map classic objects with modifiable state to stateless, side-effect-free languages like Haskell? I'd imagine that that's not going to be pretty, no matter what the underlying runtime can supposedly do, because the unpretty-ness is a function of the semantic gap between the languages themselves, not of some feature set (or lack thereof) in the runtime.
This is just more proof that the EU has a talent for demanding irrelevant stuff. If they must force companies to come up with a standard, then why not one for mechanical and electrical dimensions of laptop batteries? Rechargeable high-power batteries are real high-tech wear parts, so opening the market there and enabling battery manufacturers to sell their stuff directly to end users might actually stimulate competition and lower prices, right?
The only ways I can think of to "exhaust" (i.e. permanently destroy) a stable chemical like platinum element would be either putting it into a particle accelerator and splitting the atomic nuclei with something like fast neutrons, or shooting it into space. Everything we do it it in a fuel cell is chemistry (electron hull physics). We may have to recycle it from used cells (which might require energy), but it's not "exhausted".
What "impending end of the manned space program"? Is anyone intending to end it? Have I missed something? They just want to switch to a different vehicle, with a few years of no manned flights in between. There were no manned US flights between the last Apollo mission (1975) and the first STS mission (1981) either, so it's not as if this would be something entirely new. So what exactly is the author arguing for/against here? Continuing the Shuttle program indefinitely? Or until Ares is available?
The authors of the second amendment might have used a very similar argument to point out that a law that was made with 18th-century rifles in mind which take 1 minute to reload does not apply to fully automatic high-powered assault rifles that allow you to kill dozens of people around you before anyone could intervene.
My binder was in my backpack, and she went into my backpack to take it. Is that legal?
No.
I think for Hamas, the state of Israel is already "virtual". They even say so in their "constitution" or whatever it's called.
With but one huge, glaring, ominous difference: solid-fueled rockets cannot be switched off or throttled once ignited,
Sure.
unlike liquid-fueled or solid/liquid hybrid designs. So, while solid boosters are simpler, they preclude any kind of escape system while they are firing.
How so? What you say is true for the Shuttle, but not necessarily for a more conventional booster with an Apollo/Soyuz-like launch escape system (LES). And this is exactly what's planned for Ares I: A single solid rocket for the first stage, and an LES. The LES should provide enough thrust to be able to pull the crew compartment away from almost any kind of event that happens to the launcher, including a failure of the booster. The fact that the shuttle system doesn't have a LES is orthogonal to the fact that the shuttle system uses solid rockets. The first fact is a serious flaw, the second not so much. The Shuttle SRBs have proved to be very reliable, with over 200 succesfully flown, and only one failure: The left SRB in the Challenger accident. That failure is now well understood and its cause has been eliminated. This means that the SRBs are very reliable, even more so if you take into account that the Shuttle SRB is by far the most powerful single rocket engine ever built, and that includes the Saturn V first stage engine. And as I said, a LES would probably have saved the Challenger crew.
But they apparently haven't learned that multiple liquid-fuelled engines with one-engine-out capability are safer than solid-fuel rockets.
I don't think there's any hard data to support that allegation. Solid-fuel rockets are much simpler and thus more reliable (in general), albeit less efficient, than liquid-fuelled rockets, which makes them good candidates for the first stage. Which is where the shuttle and the proposed new system (Constellation/Ares I) uses them. The "one-engine out" capability of the shuttle isn't fully available at all times -- if the engine fails early, the shuttle must immediately return to the launch site, which is an extremely risky (and never tried) maneuver that isn't necessary with an emergency escape system as Apollo and Soyuz (and the planned Ares I) have it. Such a system was successfully used several times, and it would probably have saved the lives of the Challenger crew.
The numbers are basically correct (the "your blood boils and you die within seconds" stuff is not). Pilots use the term "useful consciousness" to describe the timespan between rapid decompression of the plane and the time at which you can no longer perform basic tasks (like putting on your oxygen mask). At 11,000 meters, this time is down to something like 20 seconds. Which is the reason why oxygen masks are automatically deployed in such a case -- there just wouldn't be enough time to manually obtain them from a storage tank or something like that.
The way patents work is even if all of us 6.7 million run to the patent office, because we all had the same idea, the first would still get it (or Edison if he were still alive).
Well, if the law doesn't spare the "2nd" inventor the need to pay the patent license, I'd say fuck the patent system. The patent system was introduced so original inventors were encouraged to publicize their invention in an orderly fashion, enabling others (the licensees) to build upon that and achieve quicker innovation cycles themselves, while the original inventor also benefits because he gets to collect the license fees. In the end, the overall rate of innovation would increase and society as a whole should be better off than it would be if there was no patent system.
However, if a second original inventor reaches the same innovation independently, he hasn't benefited from then patent system and thus shouldn't have to pay license fees. If he is still forced to pay them, the patent system has been turned on its head because it is now stifling innovations rather than encouraging them, and it would have been better if there was no patent system in the first place.
Women belong at home, making dinner and babies. God has so commanded.
No I haven't.
http://user.cs.tu-berlin.de/~klischat/aptitude-hell-1.txt
http://user.cs.tu-berlin.de/~klischat/aptitude-hell-3.txt
Advantages of RPM over DEB:
The point is that NAT and security are completely orthogonal things. The "security features" of NAT are an "en passant" effect that results from the way NAT achieves what it is designed to achieve (hide multiple hosts behind one IP address). You don't need NAT in order to have those security features. They are equivalent to the security features of a network of hosts with all global IP addresses in which the "NAT router" is replaced with a stateful packet filter that rejects all packets except ones that initiate TCP connections from the inside to the outside, or belong to such connections. NAT exists to solve one, and only one, specific problem: You want to provide (some) internet access for more devices than you have public IP addresses. If you no longer have that problem, you don't need NAT anymore. Period. No exceptions.
If you destabilise one floor there is nowhere near enough energy to collapse the whole building when the rest of it is still largely intact.
So you mean the twin towers were also brought down by secret explosives on each floor, detonated with millisecond precision? I guess that makes total sense, especially if you ignore Ockham's razor and common sense passionately enough. And don't even mention the fact that WTC 7 wasn't "largely intact" except for one floor -- it had been evacuated half an hour before the collapse because the building was cracking and quivering so much that the question wasn't if it would collapse, but when. After that, they only thought about how large the evacuated collapse zone around the building would have to be to avoid further loss of life, for god's sake.
And, if the part of the building above that floor falls one floor deep and crashes onto the lower part, what force do you think that lower part would have to endure to avoid collapsing? Hint: F = weight + F_dynamic = m*g + dp/dt = m (g+deceleration). Depending on what you assume for the deceleration distance, that gives something like 10 times the weight of the upper part -- I wouldn't be surprised if the lower part wasn't designed to withstand that.
Anyway, the most obvious proof that a building can collapse straight down under its own weight even if the lower floors are intact is the fact that we saw it happen on 9/11. Period.
just because Python implements records as dictionaries doesn't mean that languages without heterogenous dictionaries can't do records.
The point of the parent's post wasn't doing records, it was doing what you call "heterogenous dictionaries".
I'm sure Google provides an online backup service of some sort. Use that and you'll be fine.
It's been a while. I used the 3D stuff, including solid modelling (i.e. the AME package). No 2D constructions or mechanical drawing; I didn't earn money with it or anything (I was still at school back then). I used R12 for DOS and later R14 for Windows, and I didn't find the difference between those two all that great. The GUI wasn't very sophisticated or anything, and it was kind of bolted-on (which I actually liked), but I still found it essential for, well, graphical previewing and interactive point selection (mostly the snapping features mentioned earlier). Let's say I wouldn't have use the program for very long if either the command line or the GUI had been missing.
He obviously doesn't understand JavaScript (not the DOM, JavaScript is not just the DOM).
It should be obvious by now that Miguel has a mental blockade when it comes to grokking non-Microsoft technologies.
Wow, now he wants to re-implement the Gnome Panel, file manager and Evolution in Moonlight. Has he finished implementing them in Mono already? This is kinda funny -- every time Microsoft comes up with some new technology, Miguel scrambles to write a clone of it, then goes on to re-implement Gnome in that. Reimplementing stuff is so much fun anyway! If MS wants to halt all actual progress in Gnome, all have to do is churn out new hype technologies every 12 months or so.
Remember that Lisp-y language with the turtle for drawing? Completely text based, interactive drawing. You can also write javascript, microsoft shell script, and a few other languages to control/use photoshop.
Yeah. Sure you can. Please come back if professional designers or artists create their drawings using Logo or Javascript exclusively. You may not be an artist, but other people are :-P