The fact the tests were run on an emulator rather that the actual machine does put a question mark over the validity of the results. The article doesn't mention which microcontrollers are used to run the machines, but another approach would be to disassemble the source code and see what it's actually doing. The actual code (as opposed to lookup tables etc.) cant be *that* big.
You don't 'run' beowulf, it's just a generic term for a cluster of commodity hardware connected via its own private network (see the beowulf faq for more details).
>A release is nothing more than a snapshot along any >CVS branch. 4.7-RELEASE, 5.0-RELEASE, 5.1-RELEASE, >etc. No implication of stability is given by >-RELEASE.
Not quite true - in the run-up to a release there is a code freeze; only important fixes/changes are allowed to be commited.
Linux scales fine with compute-bound processes, but not so well with processes that do a lot of kernel calls. This is due to parts of the kernel still having exclusive locks ie. the second process has to wait for the first process to finish the call before it can call it.
Work is being done to improve this, but Sun (and other high-end UNIX vendors) have been working on it for a lot longer. From watching similar work being carried out for FreeBSD, I can tell you that it's not easy to do.
The article was clearly an/opinion/ piece on a piece of hardware the reviewer had bought. If you want to see bias and emotional rhetoric is, you're already in the right place:-)
Eugenia has been accused of being biased for and against just about every software platform out there. It's a shame some people can't cope with any criticism of their favourite OS.
>Now, Sun's longterm strategy (or at least it was a year ago) is to phase out Solaris in favor of Linux, and to add to Linux (and donate the code) the features that Solaris has that Linux lacks.
Erm - I really don't remember this announcement. Do you have a reference?
>No. In 4.x SMP had what was called the "giant lock". It boils down to not being able to run one given process on more than one processor. The most crude way to perform MP (does work OK though).
Not quite true. The giant lock means that only one process can call a kernel function at any one time.
> We aren't talking about bugs here, we are talking about the "legitimate" scripting capabilities of Outlook. I can still use vbscript within an email and outlook will execute it when I open the mail.
Executing of arbitrary programs? That's interesting - do you have to turn off all Outlook security settings for them to work? Do you have any examples I can look at?
>Most of the features of vbscript are security holes in and of themselves without any mistake in the code
>Are you saying complete system loss (including your personal files and everybody elses) is preferable to just losing YOUR personal files?
I'm making an counter example of your trivialising of losing personal files (ie. ones which are writable to you).
>Yes if your stupid enough to download a virus (don't forget you have to download and execute the virus yourself, there is no outlook plague on linux)
>An individual user getting wiped out because he was stupid enough to download and execute a virus nothing compared with every user, and the OS getting wiped out.
>And most of them were not, this is because the problem is not patchable. It's the inherient design of outlook entirely and express to a large degree.
Care to give some examples of non-patchable exploits? The exploit which Code Red used was fixed before the trojan actually appeared. The same for Klez. The automatic execution bug which allowed a virus to be triggered just by previewing it was fixed a *long* time ago. The main problem with Klez was that it spoofed From: e-mail addresses, which made it hard to figure out where it had come from.
A lot of these vulnerabilities were fixed a long time ago, the biggest problem is that people don't upgrade their software or apply patches. Windows Update makes it a lot easier to keep up with security patches as they are released.
The general attitude seems to be:
If a linux user gets caught out by a security bug, it's his fault. If a Windows user gets caught by a security bug, it's Microsoft's fault.
According to Bruce Mah, the reason for not creating the stable branch until at least 5.1 is to encourage people to work on fixing up the 5.x series. If a 5 STABLE branch was created first, people would more likely keep working on adding new features to HEAD.
Maybe they're not using cheap IDE drives, but expensive SCSI RAID arrays?
From the text:
'I'll say it flatly--a character record in SWG is FAR larger than you think. There's a business reality to see here. We share fancy databases over multiple servers. Said fancy databases cost $X up to a certain size. Then they cost ten times that if you go over that limit by one byte because you have to buy the "next size up." As it already stands, our programmers are nervous that we're storing too much data per character. Heck, we got asked, "You can live with 20 items in inventory max, right? 150 items total per character across the entire game?" Do the math on the items stored with a character above, and start getting scared.'
>Portupgrade under freebsd just blows chunks, and not just because yet another script interpreter (ruby) needs to be installed. It croaks a lot when dependancies somehow shift (because you compiled new versions of something). Which lieves you with the dreaded pkgdb -F which sometimes leaves you guessing.
I suggest you lok into the '-r' and '-R' options of portupgrade, it automatically handles the dependencies for you.
>Has anyone messed with installing the liquid >theme on FreeBSD? I recall I gave it a half >hearted attempt one day but something didn't >work, and I got sidetracked and never bothered >again.
cd/usr/ports/x11-wm/mosfet-liquid make install clean
> I guess someone forgot that long before windows >ever existed old school operating systems like >unix and vms were being "haxored" like there was >no tomorrow. Don't forget that the big, bad Morris >worm of 19 friggin' 88 was an exploit of BSD unix.
It wasn't 'an exploit of BSD', the worm used holes in sendmail and fingerd to propagate - it transferred source across and compiled itself on the infected machine. Once running, it would attempt to guess passwords, too.
See Clifford Stoll's 'The Cuckoo's Egg' for more details.
(I doubt that.. he stuff is not open source).. But he is definitely not part of the Free Software community. We can even consider him a parasite that tries to suck the Freedom out of our free desktops.
Slashdot Mirror
>I am currently running a model using legacy FORTRAN 90 code which was written before there were clusters.
Clustering was around for at least 10 years before Fortran90.
--Jon
>I can transfer large files from one machine to another at arround 25mb/s with my gigabit switch. Try doing that with 10/100.
:-)
My 10/100 card can manage 25 millibits per second just fine
--
Jon
When you cut and paste an old Mac flame, try to remember to change details like the model (8600/300) if you really want to wind people up. :-D
--Jon
The fact the tests were run on an emulator rather that the actual machine does put a question mark over the validity of the results. The article doesn't mention which microcontrollers are used to run the machines, but another approach would be to disassemble the source code and see what it's actually doing. The actual code (as opposed to lookup tables etc.) cant be *that* big.
--Jon
You don't 'run' beowulf, it's just a generic term for a cluster of commodity hardware connected via its own private network (see the beowulf faq for more details).
--Jon
>A release is nothing more than a snapshot along any
>CVS branch. 4.7-RELEASE, 5.0-RELEASE, 5.1-RELEASE,
>etc. No implication of stability is given by
>-RELEASE.
Not quite true - in the run-up to a release there
is a code freeze; only important fixes/changes are
allowed to be commited.
--Jon
Linux scales fine with compute-bound processes, but not so well with processes that do a lot of kernel calls. This is due to parts of the kernel still having exclusive locks ie. the second process has to wait for the first process to finish the call before it can call it.
Work is being done to improve this, but Sun (and other high-end UNIX vendors) have been working on it for a lot longer. From watching similar work being carried out for FreeBSD, I can tell you that it's not easy to do.
--Jon
The article was clearly an /opinion/ piece on a piece of hardware the reviewer had bought. If you want to see bias and emotional rhetoric is, you're already in the right place :-)
Eugenia has been accused of being biased for and against just about every software platform out there. It's a shame some people can't cope with any criticism of their favourite OS.
--Jon
>Now, Sun's longterm strategy (or at least it was a year ago) is to phase out Solaris in favor of Linux, and to add to Linux (and donate the code) the features that Solaris has that Linux lacks.
Erm - I really don't remember this announcement. Do you have a reference?
--Jon
http://www.witchspace.com
At least now Windows Update can nag Windows sysadmins that there's a new patch they should be taking an interest in...
--Jon
ISTR that the NT TCP/IP stack rewrite (wasn't it licensed from another company?) was to improve support for multi-processor systems.
--Jon
>No. In 4.x SMP had what was called the "giant lock". It boils down to not being able to run one given process on more than one processor. The most crude way to perform MP (does work OK though).
Not quite true. The giant lock means that only one process can call a kernel function at any one time.
--Jon
http://www.witchspace.com
> We aren't talking about bugs here, we are talking about the "legitimate" scripting capabilities of Outlook. I can still use vbscript within an email and outlook will execute it when I open the mail.
Executing of arbitrary programs? That's interesting - do you have to turn off all Outlook security settings for them to work? Do you have any examples I can look at?
>Most of the features of vbscript are security holes in and of themselves without any mistake in the code
I feel this is a slight exaggeration.
--Jon
>Are you saying complete system loss (including your personal files and everybody elses) is preferable to just losing YOUR personal files?
:-)
I'm making an counter example of your trivialising of losing personal files (ie. ones which are writable to you).
>Yes if your stupid enough to download a virus (don't forget you have to download and execute the virus yourself, there is no outlook plague on linux)
>An individual user getting wiped out because he was stupid enough to download and execute a virus nothing compared with every user, and the OS getting wiped out.
'Nothing' you say? Okay, type this:
rm -rf ~
It will do nothing
--Jon
>And most of them were not, this is because the problem is not patchable. It's the inherient design of outlook entirely and express to a large degree.
Care to give some examples of non-patchable exploits? The exploit which Code Red used was fixed before the trojan actually appeared. The same for Klez. The automatic execution bug which allowed a virus to be triggered just by previewing it was fixed a *long* time ago. The main problem with Klez was that it spoofed From: e-mail addresses, which made it hard to figure out where it had come from.
--Jon
If the system files are lost, I can easily restore them, eg. make installworld
If all my personal files are lost, I've got a big problem if they've changed since my last backup.
--Jon
>And yes a user can open a shell script on linux, but neither him nor his processes have acess to much unless that user happens to be root.
So you're saying that a script which recursively deletes your home directory isn't a problem?
--Jon
A lot of these vulnerabilities were fixed a long time ago, the biggest problem is that people don't upgrade their software or apply patches. Windows Update makes it a lot easier to keep up with security patches as they are released.
The general attitude seems to be:
If a linux user gets caught out by a security bug, it's his fault.
If a Windows user gets caught by a security bug, it's Microsoft's fault.
--Jon
According to Bruce Mah, the reason for not creating the stable branch until at least 5.1 is to encourage people to work on fixing up the 5.x series. If a 5 STABLE branch was created first, people would more likely keep working on adding new features to HEAD.
--Jon
Maybe they're not using cheap IDE drives, but expensive SCSI RAID arrays?
From the text:
'I'll say it flatly--a character record in SWG is FAR larger than you think. There's a business reality to see here. We share fancy databases over multiple servers. Said fancy databases cost $X up to a certain size. Then they cost ten times that if you go over that limit by one byte because you have to buy the "next size up." As it already stands, our programmers are nervous that we're storing too much data per character. Heck, we got asked, "You can live with 20 items in inventory max, right? 150 items total per character across the entire game?" Do the math on the items stored with a character above, and start getting scared.'
--Jon
>Portupgrade under freebsd just blows chunks, and not just because yet another script interpreter (ruby) needs to be installed. It croaks a lot when dependancies somehow shift (because you compiled new versions of something). Which lieves you with the dreaded pkgdb -F which sometimes leaves you guessing.
I suggest you lok into the '-r' and '-R' options of portupgrade, it automatically handles the dependencies for you.
--Jon
http://www.witchspace.com
>Has anyone messed with installing the liquid
/usr/ports/x11-wm/mosfet-liquid
>theme on FreeBSD? I recall I gave it a half
>hearted attempt one day but something didn't
>work, and I got sidetracked and never bothered
>again.
cd
make install clean
Wasn't too hard.
--Jon
http://www.witchspace.com
> I guess someone forgot that long before windows
>ever existed old school operating systems like >unix and vms were being "haxored" like there was
>no tomorrow. Don't forget that the big, bad Morris >worm of 19 friggin' 88 was an exploit of BSD unix.
It wasn't 'an exploit of BSD', the worm used holes in sendmail and fingerd to propagate - it transferred source across and compiled itself on the infected machine. Once running, it would attempt to guess passwords, too.
See Clifford Stoll's 'The Cuckoo's Egg' for more details.
--Jon
http://www.witchspace.com
Hiya
;^)
That's a different Alan Cox
--Jon
(I doubt that.. he stuff is not open source).. But he is definitely not part of the Free Software community. We can even consider him a parasite that tries to suck the Freedom out of our free desktops.
Kamera, KDE-DB and leafnode are open source.
--Jon
http://www.witchspace.com