But back then it was a) only 30 disks - now it's 400, and b) noone was making money of it.
So - I agree with the point: To make real money (i.e. enough to earn a living) off free software via documentation or support (or purchases) it either has to be a complete bugger to use (e.g. sendmail), or too large to download unless you're on a fatter pipe than ISDN.
(Back in Netscape now - Mozilla doesn't like resizing too much:))
It was really just the simple ability to build applications with full functionality with some simple lines of XML. Like a toolbar is defined using <toolbar>...</toolbar> and the buttons in there do all the bits like auto-raise when you hover the mouse over them - no more hacking Javascript to get that to work (of course you hack JS to get the rest of the app working).
I think this is going to turn a lot of IS/IT departments on - they can have their own version of netscape with their own buttons/menus and stuff like that, even completely remove the prefs menu, or just parts of it. Customisation that goes beyond the basics that IE5 provides.
Well something must be seriously wrong on my NT box then:
http://slashdot.org Viewer.exe takes 6928k mem + 4980 vmem Apprunner.exe takes 8828k mem + 7092 vmem netscape.exe takes about 12M + 15M
Better, but is it good enough??? I guess no matter what you do, building tree structures and displaying pages of gfx is always going to use up gobs of memory....
Most of the functionality is hidden at this point - or not even finished. However at least Mozilla passes the basic CSS and DOM and XML tests, unlike IE5...
Bah - IE5 can't even do XML right, and MS helped write the spec...
For those interested in the cool stuff in M3 - try editing the.xul files in res/samples - these define the entire GUI for the app. I did some playing around here and had the other web guys drooling...
I helped Rob fix the inode problem (MAX_INODE in files.h) - the problem was that on hard hit sites MySQL hit the inode limit. (at least I think it's was inodes - that's why I said "and shit" - it might have been max-open-files).
It required a kernel recompile and a reboot. So there.
And to the other guy talking about static HTML - I'd trust Win95 or an Amiga to a static HTML site. That's not something to go by - any machine can serve 2 million static HTML pages a day.
Slashdot had serious kernel level problems when it's hits started increasing. AFAIK CT had to do a recompile to fix it. Noone is going to bet a serious business on that.
Sorry, I love Linux (and/.) but I wouldn't bet a million hits/day (average) web business on it. Imagine if Slashdot were an e-commerce site and had lost sales when it had it's "Problem week" a few weeks back.
Name one. Just one. If I was running a million hits/day site I'd choose either AIX or Solaris too. Look at the problems on Linux with inodes and shit like that when you try and scale it up. Yes - I've had these problems. So has Slashdot.
From microsoft's press release on this it says they used 560 disk drives to do the test. Holy shit. That's a lot of drives...
Still, it looks like MS SQL Server proved Oracle wrong (as I was pretty sure they would). But I'm afraid it looks like they used a modified SQL Server to do it. I still say that it's because of SQL Server's heritage (Sybase) that it's fast. I'd be willing to be money that Sybase would kick Oracle's butt on this test if they used materialised views (and equivalent hardware) too.
I need a web hosting service - any ISP's out there that do good hosting with mod_perl, pop3 email, free subdomains and a good price. Contact me at msergeant@ndirect.co.uk if you've got what I need.
Oh yeah, and Bill Gates sucks. He doesn't have an original thought in his head. The Road Ahead was full of crap that had already been invented like system wide scripting (Amiga's ARexx for example), object programming and other such stuff.
Yes. It's true - the A600 is a dead machine. Not upgradable. However other Amiga's are very much alive and well, some of them are even running Linux.
You don't seem to understand. Noone is talking about reviving the A600, or even OS3.1. This is something modern and new.
Recommended URL on Amiga kernel?
on
Amiga Comeback?
·
· Score: 1
There was once a long article in Byte on Exec, however their web archive doesn't go back far enough. Exec is a simple message passing kernel that internally uses exec lists as a common data structure. Unfortunately it relies a lot on a globally shared memory system (i.e. no memory protection) - hence the need for a completely new kernel.
That's what I thought too - until I had to install perl on an AIX box. The compiler is extra (and holy cows - is it ever expensive) on AIX. So I went to www.bull.com and downloaded a "package". Actually AIX's package system was nicer than redhats....
Absolutely not - we can have "fuzzy" searches too - it just takes a bit of extra work. There's absolutely no reason why it wouldn't support a superset of the currently available features of CDDB. In fact I've been investigating search tools for this, and sgrep is looking very interesting because it does stemming automatically and some other cool stuff.
Different discid's are supported by having >1 XML file for the same CD. No problem there. That's no different to the current scheme either.
For those interested I'm in talks with Rob (the guy behind this CD Index project) about possibly using a new format that's different to CDDB. Don't fret though - it's quite possible that it could also support the CDDB protocol too.
The idea revolves around using XML. The CDDB protocol is not very flexible - it allows you only to have a disc title, and track titles (and extinfo for each track - but that's unspecified). What we would have with XML is much more flexibility, so you can have a compilation CD and the protocol will support having a different artist for each track, and you can have lyrics in there too.
The whole system just works as a web server, the XML files are stored as their discid, so you request the file http://server.com/cdids/e453f35 and you just get the raw XML back. This is very easy for the applications to parse. We can also support http://server.com/cdids/cddb/e453f35 to return the cddb format for older player, but the XML format is more flexible.
The XML format also supports indexing and searching using sgrep or other freely available tools (e.g. harvest/glimpse can be easily adapted to work with this format). This solution is infinitely more scalable than anything based on a database backend (don't believe me? Why aren't any of the web search engines run on MySQL?).
Anyway, I think it's a good idea. I know Rob already has something working, but if this is to be a truly scalable solution, with lots of different servers, then it needs some extra thought IMHO.
If you want some further info on what I am thinking about, contact me at msergeant@ndirect.co.uk
Slashdot Mirror
"It can be done"
But back then it was a) only 30 disks - now it's 400, and b) noone was making money of it.
So - I agree with the point: To make real money (i.e. enough to earn a living) off free software via documentation or support (or purchases) it either has to be a complete bugger to use (e.g. sendmail), or too large to download unless you're on a fatter pipe than ISDN.
At 56k? Most of us don't have access to our school's network, thank you.
Seriously. Not for too long though :)
(Back in Netscape now - Mozilla doesn't like resizing too much :))
It was really just the simple ability to build applications with full functionality with some simple lines of XML. Like a toolbar is defined using <toolbar>...</toolbar> and the buttons in there do all the bits like auto-raise when you hover the mouse over them - no more hacking Javascript to get that to work (of course you hack JS to get the rest of the app working).
I think this is going to turn a lot of IS/IT departments on - they can have their own version of netscape with their own buttons/menus and stuff like that, even completely remove the prefs menu, or just parts of it. Customisation that goes beyond the basics that IE5 provides.
/me wipes drool from chin...
Well something must be seriously wrong on my NT box then:
http://slashdot.org
Viewer.exe takes 6928k mem + 4980 vmem
Apprunner.exe takes 8828k mem + 7092 vmem
netscape.exe takes about 12M + 15M
Better, but is it good enough??? I guess no matter what you do, building tree structures and displaying pages of gfx is always going to use up gobs of memory....
I copied *.js and proxy.cfg from my old netscape settings to the public/bin dir. That was NT though - don't know about Linux.
Most of the functionality is hidden at this point - or not even finished. However at least Mozilla passes the basic CSS and DOM and XML tests, unlike IE5...
.xul files in res/samples - these define the entire GUI for the app. I did some playing around here and had the other web guys drooling...
Bah - IE5 can't even do XML right, and MS helped write the spec...
For those interested in the cool stuff in M3 - try editing the
I helped Rob fix the inode problem (MAX_INODE in files.h) - the problem was that on hard hit sites MySQL hit the inode limit. (at least I think it's was inodes - that's why I said "and shit" - it might have been max-open-files).
It required a kernel recompile and a reboot. So there.
And to the other guy talking about static HTML - I'd trust Win95 or an Amiga to a static HTML site. That's not something to go by - any machine can serve 2 million static HTML pages a day.
Slashdot had serious kernel level problems when it's hits started increasing. AFAIK CT had to do a recompile to fix it. Noone is going to bet a serious business on that.
/.) but I wouldn't bet a million hits/day (average) web business on it. Imagine if Slashdot were an e-commerce site and had lost sales when it had it's "Problem week" a few weeks back.
Sorry, I love Linux (and
Name one. Just one. If I was running a million hits/day site I'd choose either AIX or Solaris too. Look at the problems on Linux with inodes and shit like that when you try and scale it up. Yes - I've had these problems. So has Slashdot.
From microsoft's press release on this it says they used 560 disk drives to do the test. Holy shit. That's a lot of drives...
Still, it looks like MS SQL Server proved Oracle wrong (as I was pretty sure they would). But I'm afraid it looks like they used a modified SQL Server to do it. I still say that it's because of SQL Server's heritage (Sybase) that it's fast. I'd be willing to be money that Sybase would kick Oracle's butt on this test if they used materialised views (and equivalent hardware) too.
Matt.
I _really_ hate this - how do you fix itÂ
Why not 5.50 - the bugs in 5.10 are really irritating (in ps2pdf and when trying to create nUP printouts).
That means no StarOffice. Shit. I know it's StarDivisions fault (not Red Hat's) - but when are they going to come up with a patch?
I need a web hosting service - any ISP's out there that do good hosting with mod_perl, pop3 email, free subdomains and a good price. Contact me at msergeant@ndirect.co.uk if you've got what I need.
Oh yeah, and Bill Gates sucks. He doesn't have an original thought in his head. The Road Ahead was full of crap that had already been invented like system wide scripting (Amiga's ARexx for example), object programming and other such stuff.
Matt.
Most phone manufacturers have their own GSM modems, for example, Ericsson have the DC29. I'm sure Nokia have their own too.
Better jump on while everyone else is.
I wonder what will be the cool thing after "open source"?
My .sig isn't about using computers. It's about programming. Duh!
Yes. It's true - the A600 is a dead machine. Not upgradable. However other Amiga's are very much alive and well, some of them are even running Linux.
You don't seem to understand. Noone is talking about reviving the A600, or even OS3.1. This is something modern and new.
There was once a long article in Byte on Exec, however their web archive doesn't go back far enough. Exec is a simple message passing kernel that internally uses exec lists as a common data structure. Unfortunately it relies a lot on a globally shared memory system (i.e. no memory protection) - hence the need for a completely new kernel.
That's what I thought too - until I had to install perl on an AIX box. The compiler is extra (and holy cows - is it ever expensive) on AIX. So I went to www.bull.com and downloaded a "package". Actually AIX's package system was nicer than redhats....
Absolutely not - we can have "fuzzy" searches too - it just takes a bit of extra work. There's absolutely no reason why it wouldn't support a superset of the currently available features of CDDB. In fact I've been investigating search tools for this, and sgrep is looking very interesting because it does stemming automatically and some other cool stuff.
Different discid's are supported by having >1 XML file for the same CD. No problem there. That's no different to the current scheme either.
I think it's GPL for the server code only - not the protocol. That wouldn't exclude anything.
Checkout their notices on their web site. It quite clearly states that any data you submit to them becomes their property.
For those interested I'm in talks with Rob (the guy behind this CD Index project) about possibly using a new format that's different to CDDB. Don't fret though - it's quite possible that it could also support the CDDB protocol too.
The idea revolves around using XML. The CDDB protocol is not very flexible - it allows you only to have a disc title, and track titles (and extinfo for each track - but that's unspecified). What we would have with XML is much more flexibility, so you can have a compilation CD and the protocol will support having a different artist for each track, and you can have lyrics in there too.
The whole system just works as a web server, the XML files are stored as their discid, so you request the file http://server.com/cdids/e453f35 and you just get the raw XML back. This is very easy for the applications to parse. We can also support http://server.com/cdids/cddb/e453f35 to return the cddb format for older player, but the XML format is more flexible.
The XML format also supports indexing and searching using sgrep or other freely available tools (e.g. harvest/glimpse can be easily adapted to work with this format). This solution is infinitely more scalable than anything based on a database backend (don't believe me? Why aren't any of the web search engines run on MySQL?).
Anyway, I think it's a good idea. I know Rob already has something working, but if this is to be a truly scalable solution, with lots of different servers, then it needs some extra thought IMHO.
If you want some further info on what I am thinking about, contact me at msergeant@ndirect.co.uk