You read numbers MSD first: 'one thousand, three hundred and fifty-six'. So in English at least it makes sense to write them bigendian. The situation may be different in other languages (consider obsolete 'four and twenty blackbirds' in English).
Microsoft, a portrait of coordinated software development, doesn't have to choose between unstable bell-and-whistled programs and stable less-featured programs, because it produces stable bell-and-whistled programs.
If we're talking about OSes, then there is no comparison, because Windows doesn't include any major applications. It has a CD player, Windows Write, a web browser and a few other things where MS wants to ensure market dominance (like Media Player), but not much else. Only Linux comes with the kitchen sink by default, and so has to choose which versions of apps to install.
Some people might like that other distros give you the option of 5 different CD players, some of which may be in beta, or pre-beta - but most people just want a CD player that works.
But any user who has used Linux in the past will want his favourite CD player. Hence the need to include all five.
Only a threefold increase in speed? That would make hardly any difference, you'd get a threefold speed increase just by waiting a few years for Moore's law to deliver.
My understanding is that keys of three times the length can be cracked in about the same time - which is an _exponential_ increase in speed.
Have a look at how the EPO has interpreted the existing explicit exclusion of software from patentability. By creative interpretation of the words 'as such' they have managed to turn the meaning of the current Convention through 180 degrees. The policy following the 1997 decision was that 'any computer program with a technical effect is patentable' - and in practice any computer program can be so construed. Then in 2001 the EPO decided that the question of technical effect could itself be skipped, so computer program claims could automatically be granted.
What is needed is not to legalize the existing EPO practice of ignoring the explicit exclusion of software in Article 52(2), but rather to make the EPO's practice conform to what the law says.
We know from past experience that the EPO will take the most pro-patentability interpretation possible of any set of rules. Not allowing software 'as such' to be patented is a meaningless exclusion, since the EPO has already formulated its own definition under which all computer programs are considered to be 'software not as such'.
This directive still has to be approved by the Council of Ministers and the European Parliament, I believe. So write to your MEP and to your national representatives (or minister in charge of this area).
Some countries such as France have given public statements that a move to allowe software patents will not be approved without clear demonstration of the economic advantages (which there isn't), so there's plenty of reason to think this directive can be stopped, just like the previous Commission initiative to 'harmonize' in favour of greater patentability.
I don't think that 'requires GNOME' is a cause to label something as bloated. As the Galeon people point out, surely it is better to implement functionality once in a library and share it between all apps. The real bloat comes when every program has its own code for printing, window management, menus, and so on.
Re:They support MacOS X style app wrappers!
on
ROX Desktop Update
·
· Score: 4, Informative
The app-directory idea is neat, but it has its problems. Some things do require a central registry of applications - like associating particular file types with particular apps. So what do you do - scan the whole hard disk at boot looking for app directories and registering them?
On RISC OS each app-directory had a file inside called !Boot which was run whenever the filer _saw_ the app. Normally this was (effectively) a shell script which set some system-global environment variables for associations with particular filetypes. Needless to say this action of silently running !Boot files was a great way to spread viruses. But surprisingly opening a directory full of apps was still pretty snappy.
This system extended to libraries - a library would usually be installed as an app directory and it would need to be 'seen' by the filer before anything using that library could find it. Later on even the temporary directory (called !Scrap) did this. That is cute - you can move the temporary directory from one place to another just by clicking and dragging - but it's a nuisance that these things have to be 'seen' on every startup. IIRC there was later some method to save a session file which would visit every application seen so far, and run this session file again next time.
Since ROX-filer is just a file manager and doesn't have to set system-wide things like file assocations, it doesn't suffer from these problems AFAIK. But is there any real _need_ for app-directories?
It seems to me that they were most useful when using a handful of floppies and maybe a small hard disk; when applications were small enough to fit on a single floppy and so just copying from one disk to another was enough to 'install' an app. But how do you deal with depedencies on a particular library version, for example? Using a package manager which can check these things looks like a good idea.
Maybe a fusion of app-directories and RPM/dpkg packages would be useful. How about a package which you can double-click on to run the application immediately, but also choose to install 'centrally' (perhaps by dragging it to some strange-looking icon at the bottom of the screen) to make it install as a package, with binaries in $PATH and all that stuff.
I dunno - I liked app directories on RISC OS, but I also like Unix-style package management with install and uninstall scripts and dependency checking. And I recognize that software packaging on Unix/Linux is more complex than it was on RISC OS or even on NextStep.
One person asked if it was prototype hardware that you couldnt buy yet because it was so fast.
LOL. But in fact ROX will never be as fast as what inspired it - the RISC OS desktop (mostly) hand-written in ARM assember. Acorn's 8MHz ARM-based desktop was in fact faster than almost anything short of a Sun workstation back in 1988 when RISC OS came out, but most of the _feeling_ of speed came from the OS being implemented in assember, and on ROM so it loaded instantly. Legend has it the windowing code was written by a games programmer - perhaps the best person to pick.
Is anyone keeping an official list of 'desktop software that looks good and isn't horribly bloated like almost everything else seems to be these days, not like back when I were a lad' (tm)? I nominate Dillo and Icewm; I would use ROX-filer if I needed a file manager (I've become accustomed to using the shell now). I can't bring myself to give up XEmacs though:-(.
Who would want an HP 'home machine' anyway? Esp. after the previous Slashdot story with lots of comments about how badly made they are and how clueless / obstructionist the tech support is...
The justification for Core Linux - that it doesn't include crap which you don't need - is weakened a bit by the existence of distros like Slackware which let you choose exactly how much stuff to install.
Okay even Slackware doesn't let you go down to the _absolute_ minimum - but it is good enough for all but the crustiest hardware and most fanatical users.
I find that the limiting factor is usually disk space, followed by RAM in which to run the installer. RedHat 7.x requires lots of RAM for its installer, but 6.x is okay with twelve megs. Slackware 7.0 can manage with eight megs (with some fiddling). I currently run Slackware on one box, and a modified RH 6.1 on others. Once you're over the initial hump of installation there is no real difference between an old machine and a new one, apart from speed. I prefer to stick with mainstream distributions even at the expense of some monkeying around, rather than get diverted towards specialized GNU/Linuxes. The reason for putting Linux on the older boxes to start with is an obsession with running the same thing everywhere:-).
Galeon? Pah! Dillo is the only capable Unix/X browser that could be called 'fast'. You'll need to do some source patching if you want cookies support though (essential for Slashdot).
I'm using Dillo on a P150 right now and opening a new window is imperceptibly fast. That is, there's no perceivable delay between pressing Ctrl-N and the new window popping up. Page up, page down, back and forward are almost as quick. Netscape 4.x looks a real pig in comparison, and as for Mozilla...
Producing a modified RedHat sounds like a good idea. But it seems unlikely that the work will ever be merged back into the standard distribution. Red Hat explicitly does not support hardware below the minimum requirements, and I don't think they'd be interested in taking on that burden. Maybe the project could persuade RH to include older-system bootdisks in an unsupported/ directory on the CD, but I wouldn't expect anything more than that. Why should Red Hat spend effort modifying their installer for low-memory machines when doing so won't do anything for their target customer base? Similarly, why bother to build a kernel with support for older hardware when this would just be dead weight on the machines they do support?
Good luck to the project, but I think they'd be better off working with some distro like Debian where there is a sizable number of developers willing to make the extra effort to support old hardware.
Come off it, George Soros almost singlehandedly pulled the UK out of recession by forcing an end to the policy of overvalued exchange rate + excessively high interest rates. It was only after the government was forced to abandon its exchange rate policy that the economy started to pick up again.
You might not like the idea of currency speculators making economic decisions, but the fact is that in practice they do a much better job than most governments.
Re:Perl, Python under .NET?
on
.NETly News
·
· Score: 1
PerlNET takes any Perl code and wraps it up as a.NET component so that it can be used in any.NET application.
Sounds useful - but wasn't the whole point of.NET having this single CLR bytecode for every language?
If you can make use of.NET by writing wrappers for existing languages and runtimes, it makes the whole exercise of reimplementing every language on top of the CLR seem a bit pointless. And you have to ask what is the advantage of a.NET component over a CORBA or COM component. (Apart from that presumably lots of other people will be using.NET - which is a good enough reason in many cases.)
Perl, Python under .NET?
on
.NETly News
·
· Score: 3, Insightful
I don't think there's any big deal in ActiveState's visual Perl/Python/whatever editors. They are 'compatible with Visual Studio.NET'. What that means is that they integrate with the Visual Studio IDE - *not* that ActiveState have managed to compile Perl into.net bytecode.
At least, I assume that's the case. If somebody had managed to create.NET compilers for Perl and Python, we'd surely have heard about it by now...
Still, for all its faults, building a website on top of ACS Tcl was a lot easier than starting from scratch with a web server and RDMBS. So there was and is (openacs.org) real value in the software. ArsDigita didn't so much 'give it away', more like they made it free software because there was no good reason not to. The sort of customer who'd pay for a proprietary boxed website-building product wouldn't want something in Tcl, they'd go for something more buzzword-compliant. Hence the venture capitalists' attempt to create a new ACS Java.
(There was actually an existing port of the ACS to Java, a straight translation from Tcl. It wasn't an unworkable monster like the aborted version 5.0, but certainly less successful than the Tcl version.)
ACS Tcl was a monstrosity, but a monstrosity that worked and *made money*. Some parts were pretty terrible (esp. philg_anything as you point out) but the basic idea (let Oracle do the difficult stuff) seemed to work well. The codebase isn't beyond redemption, the OpenACS guys are having some success turning it into a respectable open source toolkit.
The Java version was at least an order of magnitude more idiotic, IMHO.
Slashdot Mirror
IIRC Windows Media Player was the one program where Microsoft released a native Linux version. It didn't last long though.
Here's a rather pointless patch for info.
You read numbers MSD first: 'one thousand, three hundred and fifty-six'. So in English at least it makes sense to write them bigendian. The situation may be different in other languages (consider obsolete 'four and twenty blackbirds' in English).
Oh sorry, I meant CDE ;-P
Only a threefold increase in speed? That would make hardly any difference, you'd get a threefold speed increase just by waiting a few years for Moore's law to deliver.
My understanding is that keys of three times the length can be cracked in about the same time - which is an _exponential_ increase in speed.
Have a look at how the EPO has interpreted the existing explicit exclusion of software from patentability. By creative interpretation of the words 'as such' they have managed to turn the meaning of the current Convention through 180 degrees. The policy following the 1997 decision was that 'any computer program with a technical effect is patentable' - and in practice any computer program can be so construed. Then in 2001 the EPO decided that the question of technical effect could itself be skipped, so computer program claims could automatically be granted.
What is needed is not to legalize the existing EPO practice of ignoring the explicit exclusion of software in Article 52(2), but rather to make the EPO's practice conform to what the law says.
We know from past experience that the EPO will take the most pro-patentability interpretation possible of any set of rules. Not allowing software 'as such' to be patented is a meaningless exclusion, since the EPO has already formulated its own definition under which all computer programs are considered to be 'software not as such'.
This directive still has to be approved by the Council of Ministers and the European Parliament, I believe. So write to your MEP and to your national representatives (or minister in charge of this area).
Some countries such as France have given public statements that a move to allowe software patents will not be approved without clear demonstration of the economic advantages (which there isn't), so there's plenty of reason to think this directive can be stopped, just like the previous Commission initiative to 'harmonize' in favour of greater patentability.
This would be useful for windows of buses and trains in areas where they tend to get vandalized.
I don't think that 'requires GNOME' is a cause to label something as bloated. As the Galeon people point out, surely it is better to implement functionality once in a library and share it between all apps. The real bloat comes when every program has its own code for printing, window management, menus, and so on.
The app-directory idea is neat, but it has its problems. Some things do require a central registry of applications - like associating particular file types with particular apps. So what do you do - scan the whole hard disk at boot looking for app directories and registering them?
On RISC OS each app-directory had a file inside called !Boot which was run whenever the filer _saw_ the app. Normally this was (effectively) a shell script which set some system-global environment variables for associations with particular filetypes. Needless to say this action of silently running !Boot files was a great way to spread viruses. But surprisingly opening a directory full of apps was still pretty snappy.
This system extended to libraries - a library would usually be installed as an app directory and it would need to be 'seen' by the filer before anything using that library could find it. Later on even the temporary directory (called !Scrap) did this. That is cute - you can move the temporary directory from one place to another just by clicking and dragging - but it's a nuisance that these things have to be 'seen' on every startup. IIRC there was later some method to save a session file which would visit every application seen so far, and run this session file again next time.
Since ROX-filer is just a file manager and doesn't have to set system-wide things like file assocations, it doesn't suffer from these problems AFAIK. But is there any real _need_ for app-directories?
It seems to me that they were most useful when using a handful of floppies and maybe a small hard disk; when applications were small enough to fit on a single floppy and so just copying from one disk to another was enough to 'install' an app. But how do you deal with depedencies on a particular library version, for example? Using a package manager which can check these things looks like a good idea.
Maybe a fusion of app-directories and RPM/dpkg packages would be useful. How about a package which you can double-click on to run the application immediately, but also choose to install 'centrally' (perhaps by dragging it to some strange-looking icon at the bottom of the screen) to make it install as a package, with binaries in $PATH and all that stuff.
I dunno - I liked app directories on RISC OS, but I also like Unix-style package management with install and uninstall scripts and dependency checking. And I recognize that software packaging on Unix/Linux is more complex than it was on RISC OS or even on NextStep.
I wonder what OS X does in this area?
LOL. But in fact ROX will never be as fast as what inspired it - the RISC OS desktop (mostly) hand-written in ARM assember. Acorn's 8MHz ARM-based desktop was in fact faster than almost anything short of a Sun workstation back in 1988 when RISC OS came out, but most of the _feeling_ of speed came from the OS being implemented in assember, and on ROM so it loaded instantly. Legend has it the windowing code was written by a games programmer - perhaps the best person to pick.
Is anyone keeping an official list of 'desktop software that looks good and isn't horribly bloated like almost everything else seems to be these days, not like back when I were a lad' (tm)? I nominate Dillo and Icewm; I would use ROX-filer if I needed a file manager (I've become accustomed to using the shell now). I can't bring myself to give up XEmacs though :-(.
Who would want an HP 'home machine' anyway? Esp. after the previous Slashdot story with lots of comments about how badly made they are and how clueless / obstructionist the tech support is...
The justification for Core Linux - that it doesn't include crap which you don't need - is weakened a bit by the existence of distros like Slackware which let you choose exactly how much stuff to install. Okay even Slackware doesn't let you go down to the _absolute_ minimum - but it is good enough for all but the crustiest hardware and most fanatical users.
I find that the limiting factor is usually disk space, followed by RAM in which to run the installer. RedHat 7.x requires lots of RAM for its installer, but 6.x is okay with twelve megs. Slackware 7.0 can manage with eight megs (with some fiddling). I currently run Slackware on one box, and a modified RH 6.1 on others. Once you're over the initial hump of installation there is no real difference between an old machine and a new one, apart from speed. I prefer to stick with mainstream distributions even at the expense of some monkeying around, rather than get diverted towards specialized GNU/Linuxes. The reason for putting Linux on the older boxes to start with is an obsession with running the same thing everywhere :-).
Galeon? Pah! Dillo is the only capable Unix/X browser that could be called 'fast'. You'll need to do some source patching if you want cookies support though (essential for Slashdot).
I'm using Dillo on a P150 right now and opening a new window is imperceptibly fast. That is, there's no perceivable delay between pressing Ctrl-N and the new window popping up. Page up, page down, back and forward are almost as quick. Netscape 4.x looks a real pig in comparison, and as for Mozilla...
Producing a modified RedHat sounds like a good idea. But it seems unlikely that the work will ever be merged back into the standard distribution. Red Hat explicitly does not support hardware below the minimum requirements, and I don't think they'd be interested in taking on that burden. Maybe the project could persuade RH to include older-system bootdisks in an unsupported/ directory on the CD, but I wouldn't expect anything more than that. Why should Red Hat spend effort modifying their installer for low-memory machines when doing so won't do anything for their target customer base? Similarly, why bother to build a kernel with support for older hardware when this would just be dead weight on the machines they do support?
Good luck to the project, but I think they'd be better off working with some distro like Debian where there is a sizable number of developers willing to make the extra effort to support old hardware.
Come off it, George Soros almost singlehandedly pulled the UK out of recession by forcing an end to the policy of overvalued exchange rate + excessively high interest rates. It was only after the government was forced to abandon its exchange rate policy that the economy started to pick up again.
You might not like the idea of currency speculators making economic decisions, but the fact is that in practice they do a much better job than most governments.
Sounds useful - but wasn't the whole point of
If you can make use of
I don't think there's any big deal in ActiveState's visual Perl/Python/whatever editors. They are 'compatible with Visual Studio .NET'. What that means is that they integrate with the Visual Studio IDE - *not* that ActiveState have managed to compile Perl into .net bytecode.
.NET compilers for Perl and Python, we'd surely have heard about it by now...
At least, I assume that's the case. If somebody had managed to create
It's been done. See MULTICS.
Still, for all its faults, building a website on top of ACS Tcl was a lot easier than starting from scratch with a web server and RDMBS. So there was and is (openacs.org) real value in the software. ArsDigita didn't so much 'give it away', more like they made it free software because there was no good reason not to. The sort of customer who'd pay for a proprietary boxed website-building product wouldn't want something in Tcl, they'd go for something more buzzword-compliant. Hence the venture capitalists' attempt to create a new ACS Java.
(There was actually an existing port of the ACS to Java, a straight translation from Tcl. It wasn't an unworkable monster like the aborted version 5.0, but certainly less successful than the Tcl version.)
ACS Tcl was a monstrosity, but a monstrosity that worked and *made money*. Some parts were pretty terrible (esp. philg_anything as you point out) but the basic idea (let Oracle do the difficult stuff) seemed to work well. The codebase isn't beyond redemption, the OpenACS guys are having some success turning it into a respectable open source toolkit.
The Java version was at least an order of magnitude more idiotic, IMHO.