Re:What happened to AdventureSHELL?
on
MUD Shell
·
· Score: 1
I'm sure the idea is older than this. I remember something called `ash', the adventure shell, that ran either on Vaxes (4.3BSD) or on an HLH Orion which ran a souped-up 4.2BSD. This was along the same lines, but it wasn't done in bash because bash didn't exist then -- I guess this was 1986-87 timeframe. If it was on the Orion it may have been local to them I think, I think at least one of the HLH people was an adventure-game type person.
ECC means it can fix any single-bit and detect any 2-bit memory error: it's one step up from parity, and what serious machines have.
Re:XML? SOAP? DOM? Bloat?
on
Inside XML
·
· Score: 1
(:foo ((:a:x (eval 'bar)) "data")) would depend on what the particular mapping did. Mine (which is really for HTML, but could do XML too) would treat the (eval 'bar) as a form to be evaluated, so you'd get the current dynamic value of BAR. There are other approaches of course.
Lisp's 40th anniversary was 1998, the only older language in general use is FORTRAN. Of course there has abeen some (quite a lot!) of development over the 43 years.
This is just stupid. XML has some seriously significant advantages over SGML, the most obvious one being that you can find the structure of a document without knowing the DTD. In SGML you can't know if:
<foo><bar></foo>
parses as
(foo (bar)) or (foo)(bar)(foo)
unless you know the DTD. In XML you can. There are lots of other cases like this. Being able to find the structure without knowing the DTD is useful for the same reasons that Lisp's READ function is useful.
I think XML is hopeless, but it's *much less* hopeless than SGML, which was completely losing.
Re:XML? SOAP? DOM? Bloat?
on
Inside XML
·
· Score: 1
Well, of course, Lisp (or Scheme) syntax really
*is* XML, except without so much syntactic baggage -- it's a trivial operation to convert from, say
(:foo ((:a:x "1") "data"))
to
<foo><a x='1'>data</a></foo>
and only slightly less trivial to convert back.
Lisp people tend to get a bit bitter about the reinvention of something they've known about for more than 40 years, but then we like to be bitter.
As for using Lisp/scheme syntax for doing RPC-type things: yes, we do that too, it works pretty well.
The super shell, ssh, was a Bourne-shell related
shell which had job control and various other cool features. It dates from the late 80s and was still in use in the early 90s. I used it until bash became good enough to use. It probably still exists somewhere (I know the author quite well).
Given this, do these SSH upstarts stand any chance at all?
Well there are some reasons why Sun (or any other serious HW vendor) make fairly expensive machines:
They will support these machines for a long time -- I guess 5 years or so. Keeping spares for that long cranks up the price.
The large majority of these machines will have support contracts. This means that they need to be reliable, because if they're not then they will cost the vendor later to support. Making reliable machines costs money.
They have stuff like ECC memory, does your PC?
From the buyer's point of view:
These machines have long lives. We've just stopped using an IPX from (?) 1992. Sure it was slow, but it ran Solaris 7 OK, and it made a fine X terminal. We might still revive it to do something like DNS or print serving. I worked somewhere that had a Sun 3 on maintenance until 1996 or so (and they fixed it in 1996 too): it was 11 when we turned it off.
Professional boxes are typically very homogenous -- if you buy a Sun (or an HP or whatever), then it will run pretty much the same OS image that all your other boxes will run: you won't have to spend time mucking around with some weirdo graphics card. That's a big deal.
When bits go wrong they'll get replaced, and they'll get replaced by bits that work the same way: you won't have to spend ages finding drivers for the new graphics card they shipped you because they don't have the old ones any more.
They also run the same systems your big box in the basement runs, so you can develop code on a (relatively) cheap machine without having to worry too much about porting it all the time. In fact this is why people like Sun sell workstations I think: I doubt they make much money on them compared to what they make on E10ks.
In summary, They aren't that expensive if you get paid. Sure if your time is worth nothing, then saving a couple of thousand dollars when you buy a machine amtters a lot. But if your time costs money then the time you save because of the points above more than pays for the extra up-front cost.
Of course that's not to say that Suns aren't quite expensive: they are, but the difference is basically in the noise for many purposes.
And of course there are plenty of cases where a Sun won't cut it -- for instance if you really need lots of raw CPU performance, either for some single-processor machine or some embarrasingly parallel problem which you can solve with a farm of PCs. PCs beat Suns every time for Quake...
Although I wasn't particularly thinking of Java in my original comment -- Java isn't the only bounds-checked language, though it's obviously a particularly popular one right now -- Having a C/C++ runtime is still not so bad as you might think.
I kind of hope that most of the libraries are, mostly, in Java: it's a whole lot more convincing if the language can eat its own dogfood, especially since the language is meant to be trusted to run random code downloaded from the net, which could be specially devised to exploit weaknesses in the libraries. But the VM probably can't be, and some core of the libraries is likely not to be (though this core could be OS system calls). So there is probably going to be some significant amount of C/C++ in a Java system, unlike a native-code system.
But this is a constant core of code, which *all* Java programs share. So you only have to check it once, and once you're sure it's safe, it's safe for all Java programs. This is completely different than a program which is itself implemented in a non-bounds-checked language: every program now has to be checked for overflow problems. This means you have constant work to do (check the libs and the VM) rather than work proportional to the number of programs you might want to run.
I think this is likely to deteriorate into a language war, so I'll stop after this, but:
My main point is that you can't rely on other people to know what needs checking: empirically, they don't.
A language which does bounds checks doesn't have to check every access: it's often possible to prove things about the code and move checks out of loops, and so on. It's also possible for the compiler to warn you when it can't do this, so you can make declarations which enable it to prove more things. This is not new technology!
It is, I suspect, hard to do this in a language which offers bounds checking as a bolt-on extra, like C++ (by overloading [] for instance): you need the compiler to really know about it.
Serious implementations of languages that offer bounds checking should offer ways of saying that it's just safe to assume everything is OK in a bit of code, and so compile code which has no checks. You need this in a per-block basis, not per file, so you can bum only the places where you know the time is being spent.
Bounds checks are not that expensive in any case -- the compiler should be able to get the index and the bound into a register at the start of any loop, and do a register comparison, which is seriously cheap compared to touching memory (which you're about to do when you access the array...). Again, having the compiler know about the checking is a win here.
Not that much code is speed-critical in ways that bounds-checking will hurt -- for instance I doubt that many instances of BIND would be constrained by bounds-checking overhead! Some code obviously is, and I'm not suggesting that there should not be ways of making this stuff not need to check. Importantly, a performance profiler can find these parts of the code for you pretty reliably.
In summary, what I'm trying to say is that, purely empirically, most people do *not* know where the problems are in their code (any more than they know where the performance bottlenecks are without profiling), and that therefore I'd like to see people write using languages which were safe-by-default with compilers that can optimise away checks, and the option of turning off safety for performance-critical parts of the code. Working this way means that you can use a well-defined performance profiler to tell you where you might need to *not* bounds check, rather than some typically poorly-defined test-suite which might find the places where you do need to check.
Of course, I don't see much chance of this happening because worse is better, but I can dream.
It is obviously hard enough to do things safely by hand that people do not do it: that's really all that matters. Obviously it is *possible* to write safe code in a non-bounds-checked language, but it is hard enough that people generally don't, so we have buffer-overflow vulnerabilities in critical code every few months.
I'm not really interested in an argument that it's possible to write bounds checking code by hand -- obviously it is (and I'm sure you do!) -- but equally obviously, many, possibly most, people do not.
I can see two fixes to this problem:
Educate people to write better code. So far there hasn't been much progress here: possibly there has been negative progress.
Start writing critical software in languages which check array bounds both at compile time where possible -- which can eliminate runtime overhead -- and at runtime where needed, and handle out-of-bounds accesses gracefully.
These vulnerabilities cost huge amounts every time they happen, not just in terms of security breaches but in all the hidden cost of time spent upgrading systems. How many DNS servers are there running vulnerable versions of BIND right now? How long will it take to fix them, assuming they get fixed? This is really a lot of money...
I kind of wish education could solve this problem, but I'm cynical, so I place more faith in systems which prevent it happening.
If you implement security critical software in a language which has no bounds checking, I think you get what you deserve.
Seriously: there must be so much evidence by now that it is just too hard for human beings to do all the bounds checking by hand that I'm fairly surprised that security critical code is still written in C.
I've never looked at any of the securified versions of things like BIND, but I suspect they do it by inventing a bounds-checked framework in which they then write the code...
I think.NET is microsoft's strategy for coping with being possibly being split in two. The theory is that they will (may...) get split into an OS division, and an applications division. Because these will be different companies, they will be encouraged to publish specifications, support third party apps (in the case of the OS division) port (in the case of the apps division) to non-Windows OSs and so on. This means they lose market share which is not what they want.
So what does.NET do? Well,.NET is an `application', not an OS. So it's controlled by the applications division. But is.NET succeeds, then it will be the platform for which applications are written. So the applications division now controls the platform on which applications are written, just the same way that MS as a whole controls the platform on which applications are written too.
So a magic trick is being done: MS can be split, the applications division will get monopoly control ofer platform and applications, and the OS division will either compete as a sub-platform on which to run.NET or just wither and die slowly.
From this point of view, I think that.NET is not like Java. Sun would undoubtedly like to be a monopolist, but they're really not, so they can't exercise the control over Java that MS (or the applications division of MS) will over.NET. From Sun's point of view, if they can cause people to write applications that will be OS-neutral they will win, even if that means they can be ported away from Sun's OS -- they have more to gain than lose, simply because of the statistics.
.NET isn't like this at all; it's something altogether nastier.
I think OSS projects are *differently* responsive, not more or less.
Closed source things, if you're paying for them, and if they're not in some kind of monopoly position, really *have* to be responsive if they want to keep selling the product. (And it isn't necessarily the case that you don't have access to the developers of course.)
Open source projects which you're not paying for don't *have* to be responsive in this way and often are not, but they are usually responsive in a different way: if you decide you want some feature, and implement it in a competent way, then it's often likely to make it into the sources. You are dependent on the fractiousness of the people who are running the project of course, and some OSS people are pretty fractious, but this often works out OK.
A third category, often ignored, is OSS projects which you *are* paying for -- for instance buying support for some OSS system. For these things you should get very good responsiveness, especially as you can audit the changes.
I think that this (and some other messages here) kind of miss the point. For many billing-type applications the billing system *is* how the organisation makes money. So it's *really* important that things don't crash, but it's even more important that when they do, or when somebody does something funny, you don't lose data or leave the database in a bad state.
Someone said that you need to do things in the right order to make sure stuff is OK. Yes, you do, but does this fix the case where n different things are trying to do the same thing in parallel, and exactly one must complete while all the others must be rolled back? And someone trips over the disk cable half way through this process. These things do happen, and since this thing is how you make money you want to be very sure you can recover from them.
As far as I can see there are two ways to do this kind of thing: either you serialise access to the database by large-scale locks, together with some kind of rollback system, or you have a hairy transactional system. The former solution is OK if you don't have very high throughput, or if the load can be easily serialised, like some kind of run-nightly batch system. If you have high throughput and lots of parallel updates, then I think you're either going to end up either writing or obtaining a transactional system or going out of business at some point when the system eats your data.
No, it won't work, unless you get the right phone. In the UK and Europe, GSM phones work on 900 or 1800 MHz. In the US most (all?) GSM works on 1900MHz, so it just won't work.
You can get triple band phones (I have one), but they're not that common.
Alternatively you can just take your SIM card and hire a phone in the US.
To bring this back to the original (drifted...) topic: in the UK you'd expect to pay about L15 (maybe $22?) a month for a contract which is either a lot of inclusive offpeak minutes (perhaps 50 a day) and rather expensive peak time, or perhaps 60 inclusive peak minutes per month and then more-reasonably priced calls the rest of the time. These typically all work for calls to landlines and other people on the same network -- off-network calls are more. Incoming calls are all free of course, and voicemail is often free too, and you get the usual stuff like fax & messaging. It;s attractive enough that my company has no fixed-line phones at all, and probably never will have.
MS might well consider compiling to native code an advantage. Bytecodes give you portability -- at least in theory -- and portability is not interesting to MS since they essentially only run on x86. This is the company who provides the documentation for this language wrapped in a.EXE file.
Of course, bytecodes also give you some hope of safety, but MS probably don't care much about that, and if they do they'd rather provide it via signatures, as they can then control the signatures.
It's kind of interesting that the Solaris 8 media kit (all you get unless you buy the documentation set on paper, which is obviously huge) is in a fairly small box, and it's full. I'm not completely sure what this says: it would be interesting to compare the packaging with other `professional' products. I suspect that people who buy these things tend to be concerned quite a lot about shelf-space, so small is good.
There may also be a European / US difference here -- in the UK, we never had CDs in anything other than jewel boxes for instance.
I think it's clear that it, or its successors, will see the light of day. Intel really need to have a 64bit processor, so they have to produce something. Of course it could fail, but I don't think they will just give up. And if it does fail they will try something else.
You want analysis... There are 400 people relying on this machine for name service. Something is wrong with named and/or NIS on the machine. None of those 400 people are doing useful work right now, and this is conservatively costing $40,000 an hour.
What do you do: sit for an hour (or 10 minutes) and try and work out what is wrong, or reboot it now with the strong expectation that the failure is transient and it will just come back, and then try and work out what was wrong.
It's extremely tempting to do the first, but experience shows that machines just get fouled up sometimes -- the implementation languages we choose make it very hard to write systems without memory leaks and so on which cause long-term lossage. Quite often the professional answer is `just reboot', because quite often that will fix the problem and give you a chance to file a bug report and/or grovel through the source without it costing thousands of dollars an hour.
It measures nothing. In particular I really doubt that most Solaris people come from NT backgrounds. Rather, most people running serious machines will simply not bother to install some random daemon to let other people know information that they don't particularly want to give away. I can see Solaris machines with 285 day uptimes from here, and they aren't particularly special.
I also must take issue with the `uptime being a point of pride' thing. If the machine doesn't have any particular state (say it's an NFS server), and it's going to take some time to work out what's wrong with it, the professional thing to do is just reboot it: only some idiot who isn't accounting for their time properly is going to spend half a day trying to work out what's wrong with it without rebooting first to make sure it's not something transient
There was a tool around in the late 80s in the UK from (I think?) the UKC toolset which did a visual diff with a split window and simultaneous scrolling &c. It might well originate pre-1986 and it looks really close to what they are claiming.
Perhaps some other UK-based person remembers the name of it?
The version I used ran on X (perhaps originally X10) but it may trace its origins to some earlier window system.
Sigh, yes it *is* interesting: it is exactly because they are in a hugely profitable business that they can afford the large costs involved in reinventing themselves to be an e-business. Of course (as the feature says, talking about lucent), it also helps that they are a relatively new company and so have little history to throw away. Cisco are about as bad an example as you could pick of what e-commerce means for most companies.
But cisco are in a market which is exploding. It would be hard for them not to make money at this point! Car manufacture or something is a bunch more interesting.
The feature is kind of interesting, but it fails to mention some of the downsides. A couple of obvious ones are
cost of change. They say that e-commerce will `transform' business, and that the rate of change will be enormous. Yet change is expensive, and rapid change is very expensive. It's already seriously hard to keep up with the rate things are changing, and this looks like yet more `let's reorganise!' fever. Completely transforming the way you work means completely reeducating most of your employees, and education is not cheap. And people don't actually like spending their lives racing to keep up.
Immaturity of technology. None of this existed 5 years ago; everything they are talking about has been written in a huge hurry by people desperate to ride some wave of fashion -- the least stable program I use is netscape, and I wonder how good all the other stuff involved is. I wouldn't trust my business to anything netscape wrote, and I'm sure all the other people pushing stuff are producing similar quality systems, because they are in such a tearing hurry.
I think The Economist is touchingly naive about computing-related issues, and this is a good example. Somewhere in the feature the author suggests that the internet will finally be the silver bullet that brings all the productivity improvements that computers have promised, but failed to deliver, for so long. I doubt it.
It's not different at all, of course (except that there are three companies which makes it a trust and not a monopoly perhaps).
There seems to be an assumption that microsoft is somehow `evil'. This is wrong. They are just doing the best they can to make money, the same as any company will. Sun would do the same thing if they were in microsoft's shoes (as would I). Because Microsoft are a monopoly, their attempts to make money hurt the consumer, but it's not their fault they are a monopoly, it's just that free markets are vulnerable to this kind of cascade runaway where all power ends up with one organisation.
So of course, it will not be fifferent. All we can hope is that the anti monopoly laws are enforced sooner next time around.
Slashdot Mirror
I'm sure the idea is older than this. I remember something called `ash', the adventure shell, that ran either on Vaxes (4.3BSD) or on an HLH Orion which ran a souped-up 4.2BSD. This was along the same lines, but it wasn't done in bash because bash didn't exist then -- I guess this was 1986-87 timeframe. If it was on the Orion it may have been local to them I think, I think at least one of the HLH people was an adventure-game type person.
ECC means it can fix any single-bit and detect any 2-bit memory error: it's one step up from parity, and what serious machines have.
Lisp's 40th anniversary was 1998, the only older language in general use is FORTRAN. Of course there has abeen some (quite a lot!) of development over the 43 years.
<foo><bar></foo>
parses as
(foo (bar)) or (foo)(bar)(foo)
unless you know the DTD. In XML you can. There are lots of other cases like this. Being able to find the structure without knowing the DTD is useful for the same reasons that Lisp's READ function is useful.
I think XML is hopeless, but it's *much less* hopeless than SGML, which was completely losing.
(:foo ((:a
to
<foo><a x='1'>data</a></foo>
and only slightly less trivial to convert back.
Lisp people tend to get a bit bitter about the reinvention of something they've known about for more than 40 years, but then we like to be bitter.
As for using Lisp/scheme syntax for doing RPC-type things: yes, we do that too, it works pretty well.
Given this, do these SSH upstarts stand any chance at all?
- They will support these machines for a long time -- I guess 5 years or so. Keeping spares for that long cranks up the price.
- The large majority of these machines will have support contracts. This means that they need to be reliable, because if they're not then they will cost the vendor later to support. Making reliable machines costs money.
- They have stuff like ECC memory, does your PC?
From the buyer's point of view:- These machines have long lives. We've just stopped using an IPX from (?) 1992. Sure it was slow, but it ran Solaris 7 OK, and it made a fine X terminal. We might still revive it to do something like DNS or print serving. I worked somewhere that had a Sun 3 on maintenance until 1996 or so (and they fixed it in 1996 too): it was 11 when we turned it off.
- Professional boxes are typically very homogenous -- if you buy a Sun (or an HP or whatever), then it will run pretty much the same OS image that all your other boxes will run: you won't have to spend time mucking around with some weirdo graphics card. That's a big deal.
- When bits go wrong they'll get replaced, and they'll get replaced by bits that work the same way: you won't have to spend ages finding drivers for the new graphics card they shipped you because they don't have the old ones any more.
- They also run the same systems your big box in the basement runs, so you can develop code on a (relatively) cheap machine without having to worry too much about porting it all the time. In fact this is why people like Sun sell workstations I think: I doubt they make much money on them compared to what they make on E10ks.
In summary, They aren't that expensive if you get paid. Sure if your time is worth nothing, then saving a couple of thousand dollars when you buy a machine amtters a lot. But if your time costs money then the time you save because of the points above more than pays for the extra up-front cost.Of course that's not to say that Suns aren't quite expensive: they are, but the difference is basically in the noise for many purposes.
And of course there are plenty of cases where a Sun won't cut it -- for instance if you really need lots of raw CPU performance, either for some single-processor machine or some embarrasingly parallel problem which you can solve with a farm of PCs. PCs beat Suns every time for Quake...
I kind of hope that most of the libraries are, mostly, in Java: it's a whole lot more convincing if the language can eat its own dogfood, especially since the language is meant to be trusted to run random code downloaded from the net, which could be specially devised to exploit weaknesses in the libraries. But the VM probably can't be, and some core of the libraries is likely not to be (though this core could be OS system calls). So there is probably going to be some significant amount of C/C++ in a Java system, unlike a native-code system.
But this is a constant core of code, which *all* Java programs share. So you only have to check it once, and once you're sure it's safe, it's safe for all Java programs. This is completely different than a program which is itself implemented in a non-bounds-checked language: every program now has to be checked for overflow problems. This means you have constant work to do (check the libs and the VM) rather than work proportional to the number of programs you might want to run.
There, this is really my last comment on this!
- My main point is that you can't rely on other people to know what needs checking: empirically, they don't.
- A language which does bounds checks doesn't have to check every access: it's often possible to prove things about the code and move checks out of loops, and so on. It's also possible for the compiler to warn you when it can't do this, so you can make declarations which enable it to prove more things. This is not new technology!
It is, I suspect, hard to do this in a language which offers bounds checking as a bolt-on extra, like C++ (by overloading [] for instance): you need the compiler to really know about it.
- Serious implementations of languages that offer bounds checking should offer ways of saying that it's just safe to assume everything is OK in a bit of code, and so compile code which has no checks. You need this in a per-block basis, not per file, so you can bum only the places where you know the time is being spent.
- Bounds checks are not that expensive in any case -- the compiler should be able to get the index and the bound into a register at the start of any loop, and do a register comparison, which is seriously cheap compared to touching memory (which you're about to do when you access the array...). Again, having the compiler know about the checking is a win here.
- Not that much code is speed-critical in ways that bounds-checking will hurt -- for instance I doubt that many instances of BIND would be constrained by bounds-checking overhead! Some code obviously is, and I'm not suggesting that there should not be ways of making this stuff not need to check. Importantly, a performance profiler can find these parts of the code for you pretty reliably.
In summary, what I'm trying to say is that, purely empirically, most people do *not* know where the problems are in their code (any more than they know where the performance bottlenecks are without profiling), and that therefore I'd like to see people write using languages which were safe-by-default with compilers that can optimise away checks, and the option of turning off safety for performance-critical parts of the code. Working this way means that you can use a well-defined performance profiler to tell you where you might need to *not* bounds check, rather than some typically poorly-defined test-suite which might find the places where you do need to check.Of course, I don't see much chance of this happening because worse is better, but I can dream.
I'm not really interested in an argument that it's possible to write bounds checking code by hand -- obviously it is (and I'm sure you do!) -- but equally obviously, many, possibly most, people do not.
I can see two fixes to this problem:
These vulnerabilities cost huge amounts every time they happen, not just in terms of security breaches but in all the hidden cost of time spent upgrading systems. How many DNS servers are there running vulnerable versions of BIND right now? How long will it take to fix them, assuming they get fixed? This is really a lot of money...
I kind of wish education could solve this problem, but I'm cynical, so I place more faith in systems which prevent it happening.
Seriously: there must be so much evidence by now that it is just too hard for human beings to do all the bounds checking by hand that I'm fairly surprised that security critical code is still written in C.
I've never looked at any of the securified versions of things like BIND, but I suspect they do it by inventing a bounds-checked framework in which they then write the code...
So what does .NET do? Well, .NET is an `application', not an OS. So it's controlled by the applications division. But is .NET succeeds, then it will be the platform for which applications are written. So the applications division now controls the platform on which applications are written, just the same way that MS as a whole controls the platform on which applications are written too.
So a magic trick is being done: MS can be split, the applications division will get monopoly control ofer platform and applications, and the OS division will either compete as a sub-platform on which to run .NET or just wither and die slowly.
From this point of view, I think that .NET is not like Java. Sun would undoubtedly like to be a monopolist, but they're really not, so they can't exercise the control over Java that MS (or the applications division of MS) will over .NET. From Sun's point of view, if they can cause people to write applications that will be OS-neutral they will win, even if that means they can be ported away from Sun's OS -- they have more to gain than lose, simply because of the statistics.
Closed source things, if you're paying for them, and if they're not in some kind of monopoly position, really *have* to be responsive if they want to keep selling the product. (And it isn't necessarily the case that you don't have access to the developers of course.)
Open source projects which you're not paying for don't *have* to be responsive in this way and often are not, but they are usually responsive in a different way: if you decide you want some feature, and implement it in a competent way, then it's often likely to make it into the sources. You are dependent on the fractiousness of the people who are running the project of course, and some OSS people are pretty fractious, but this often works out OK.
A third category, often ignored, is OSS projects which you *are* paying for -- for instance buying support for some OSS system. For these things you should get very good responsiveness, especially as you can audit the changes.
I think that this (and some other messages here) kind of miss the point. For many billing-type applications the billing system *is* how the organisation makes money. So it's *really* important that things don't crash, but it's even more important that when they do, or when somebody does something funny, you don't lose data or leave the database in a bad state.
Someone said that you need to do things in the right order to make sure stuff is OK. Yes, you do, but does this fix the case where n different things are trying to do the same thing in parallel, and exactly one must complete while all the others must be rolled back? And someone trips over the disk cable half way through this process. These things do happen, and since this thing is how you make money you want to be very sure you can recover from them.
As far as I can see there are two ways to do this kind of thing: either you serialise access to the database by large-scale locks, together with some kind of rollback system, or you have a hairy transactional system. The former solution is OK if you don't have very high throughput, or if the load can be easily serialised, like some kind of run-nightly batch system. If you have high throughput and lots of parallel updates, then I think you're either going to end up either writing or obtaining a transactional system or going out of business at some point when the system eats your data.
You can get triple band phones (I have one), but they're not that common.
Alternatively you can just take your SIM card and hire a phone in the US.
To bring this back to the original (drifted...) topic: in the UK you'd expect to pay about L15 (maybe $22?) a month for a contract which is either a lot of inclusive offpeak minutes (perhaps 50 a day) and rather expensive peak time, or perhaps 60 inclusive peak minutes per month and then more-reasonably priced calls the rest of the time. These typically all work for calls to landlines and other people on the same network -- off-network calls are more. Incoming calls are all free of course, and voicemail is often free too, and you get the usual stuff like fax & messaging. It;s attractive enough that my company has no fixed-line phones at all, and probably never will have.
Of course, bytecodes also give you some hope of safety, but MS probably don't care much about that, and if they do they'd rather provide it via signatures, as they can then control the signatures.
There may also be a European / US difference here -- in the UK, we never had CDs in anything other than jewel boxes for instance.
I think it's clear that it, or its successors, will see the light of day. Intel really need to have a 64bit processor, so they have to produce something. Of course it could fail, but I don't think they will just give up. And if it does fail they will try something else.
You want analysis...
There are 400 people relying on this machine for name service. Something is wrong with named and/or NIS on the machine. None of those 400 people are doing useful work right now, and this is conservatively costing $40,000 an hour.
What do you do: sit for an hour (or 10 minutes) and try and work out what is wrong, or reboot it now with the strong expectation that the failure is transient and it will just come back, and then try and work out what was wrong.
It's extremely tempting to do the first, but experience shows that machines just get fouled up sometimes -- the implementation languages we choose make it very hard to write systems without memory leaks and so on which cause long-term lossage. Quite often the professional answer is `just reboot', because quite often that will fix the problem and give you a chance to file a bug report and/or grovel through the source without it costing thousands of dollars an hour.
It measures nothing. In particular I really doubt that most Solaris people come from NT backgrounds. Rather, most people running serious machines will simply not bother to install some random daemon to let other people know information that they don't particularly want to give away. I can see Solaris machines with 285 day uptimes from here, and they aren't particularly special.
I also must take issue with the `uptime being a point of pride' thing. If the machine doesn't have any particular state (say it's an NFS server), and it's going to take some time to work out what's wrong with it, the professional thing to do is just reboot it: only some idiot who isn't accounting for their time properly is going to spend half a day trying to work out what's wrong with it without rebooting first to make sure it's not something transient
This survey is worthless.
There was a tool around in the late 80s in the UK from (I think?) the UKC toolset which did a visual diff with a split window and simultaneous scrolling &c. It might well originate pre-1986 and it looks really close to what they are claiming.
Perhaps some other UK-based person remembers the name of it?
The version I used ran on X (perhaps originally X10) but it may trace its origins to some earlier window system.
--tim
Sigh, yes it *is* interesting: it is exactly because they are in a hugely profitable business that they can afford the large costs involved in reinventing themselves to be an e-business. Of course (as the feature says, talking about lucent), it also helps that they are a relatively new company and so have little history to throw away.
Cisco are about as bad an example as you could pick of what e-commerce means for most companies.
But cisco are in a market which is exploding. It would be hard for them not to make money at this point! Car manufacture or something is a bunch more interesting.
The feature is kind of interesting, but it fails to mention some of the downsides. A couple of obvious ones are
I think The Economist is touchingly naive about computing-related issues, and this is a good example. Somewhere in the feature the author suggests that the internet will finally be the silver bullet that brings all the productivity improvements that computers have promised, but failed to deliver, for so long. I doubt it.
It's not different at all, of course (except that there are three companies which makes it a trust and not a monopoly perhaps).
There seems to be an assumption that microsoft is somehow `evil'. This is wrong. They are just doing the best they can to make money, the same as any company will. Sun would do the same thing if they were in microsoft's shoes (as would I). Because Microsoft are a monopoly, their attempts to make money hurt the consumer, but it's not their fault they are a monopoly, it's just that free markets are vulnerable to this kind of cascade runaway where all power ends up with one organisation.
So of course, it will not be fifferent. All we can hope is that the anti monopoly laws are enforced sooner next time around.