Not proprietary, but NetBSD, Linux and (iirc) OpenBSD all run fine on sparc64. Indeed, I have a vague notion Sun gave David Miller access to some big Sparc64 machines to help test Linux Sparc64 on big SMP Sparc64 boxes (but i could be wrong).
Plain and simple, because they fear competition. By being GPL, it allows others to benefit from their work (and work that they received from others). By going with CDDL, only they become the all inclusive taker. It is similar to the MS shared source. But unlike MS, when SUN's shares start sinking (and they will), Sun will move over to the GPL, still have a losing market and then state that GPL does not work.
Rubbish. As already described several times on the blogs of important Sun people, they considered the GPL quite seriously, but found it wasn't suitable. One obvious reason is that the GPL is slightly too restrictive for OpenSolaris - not all hardware vendors want to have to release source, which coding to a GPL'd driver interface would almost certainly require. The CDDL allows ISVs to decide for themselves whether to open their code or not. Sun wrote and/or own Solaris, Sun wanted to allow others to be able to use it without having to release their modifications (remember, Sun has strong BSD roots), so Sun fixed the problems in the MPL to create the CDDL. Further, the GPL does not deal with the problem of patent litigation in any meaningful way (one of the goals for GPLv3 apparently is to do that - hopefully they'll draw from the CDDL approach to patents, which is quite nice.).
I fail to see how working towards releasing Solaris under a liberal licence such as the CDDL qualifies as trying to "hold on to a monopoly".
If you think this is bogus, consider that many many Linux users who are happy to bash the CDDL are using proprietary kernel drivers, particularly for graphics cards, which are in possibly in a grey legal area wrt GPL status of Linux - particularly the ATi drivers, which are (IIRC) based on DRI in some way (the NVidia drivers arent).
Note that Sun do not have a problem with the GPL. There are lots of GPL and LGPL projects out there whose ChangeLogs contain @sun.com addresses, eg GNOME and OpenOffice to name just two (Indeed, Sun bought out and then LGPL'd OpenOffice). And I'm very involved in a GPL project myself..
It's a real shame there is such anti-Sun hysteria on/. and other "open source" community sites. If the Sun-haters were to have their way and see Sun fail then a good[1] number of open-source hackers would be out of work (including myself).
Thanks.
1. And I dont include OpenSolaris hackers in that. Once OpenSolaris is out there, virtually every Sun engineer working on Solaris will be an open-source hacker too.
I think we [the U.S.] should institute weight/horsepower classes like they do for two-wheeled vehicles in Japan, but for all types of vehicles.
I did far dumber stuff, got into far more danger on a regular basis, had more crashes and broke more bones on my 50cc 3hp/70kg Kawa AR50 when I was a teenager than I ever did on my 250cc 60hp/140kg RS250 as young twenty-something. Even that pathetic 50cc AR50 can get up to 85km/h, which is more than enough to get badly hurt.
It comes down not to power/weight ratio, but to *experience*. Indeed, the higher risks insurers of motorcycles in this country have is of the small *low power* motorcycles, because small low-power bikes tend to be ridden by new riders. Some of the other high-risk categories are "new age bikers", middle aged men who return to motorcycles and can afford the insurance on big bikes, but its their inexperience which kills them, not the power of the bike - they'd likely have had the same accident on a low-power bike.
Inexperience will get you hurt on a motorcycle, low or high power regardless. However, decent power can be a good thing, an aide to safety: it gives you a last-resort option which you dont have on a tweeny bike, the power to possibly get out of trouble really quickly with a twist of the wrist. Removing this option from/all/ bikers, simply because of inexperienced bikers (who'd get into trouble regardless of the power of their bike), is a dumb idea.
Hmm.. it's a great spin on the fact that there's neither the political will nor the appetite to paw over the kernel device driver interface and create a full, strict, detailed and fully thought out interface document to which the kernel and device drivers can be written and verified against and have it imposed on the kernel and driver developers.
But there's the problem in a nutshell "imposed on the kernel and driver developers", who, pray tell, is going to do that? Further, from a resource allocation point of view, if one could "impose" in such a way on the kernel developers, is it a good idea to divert resources away from hacking on other things and onto designing, implementing and sustaining to-be-set-in-stone driver interfaces? And once that's done and a problem is found in the interface (which will always occur), what do you do then?
Maintaining guaranteed ABIs for significant periods of time can be very very difficult and resource consuming, hence not everyone cares to take the time to do it. For Linux, where the vast bulk of drivers are maintained in the kernel, by the kernel people, alongside the rest of the core kernel code, it doesn't make sense to spend time guaranteeing interfaces for a very few 3rd party drivers. Note that there are other kernels which do provide such ABI stability for 3rd party drivers. You are quite free to use them.
Or find a Linux distro maker who you can pay to support binary drivers. If so many Linux users think it is so needed, I'm sure someone would be willing to take your Euro's to provide it...
In short, your choices are:
- lobby your vendor for open-drivers and/or programming specifications for your hardware (cause then it can be integrated into Linux kernel, the kernel people will help maintain it, and other kernel's can benefit from having source/docs to look at to help implement their own drivers).
- Put your money (collectively or not) where your mouth is and pay someone to take care of this, obviously highly critical, missing functionality.
- Go use a different system which does provide this highly critical functionality you need.
or finally:
- Continue using Linux and stop whinging
I would like to see Linux succeed. However, the way it's going at the moment I can see it becoming an interesting footnote in history.
Wow, Linux is dying!!! That's a new one on slashdot.
He may not manage them in the traditional sense of the word, but when they are making statements to driver developers that flatly contradict Linus' official policy and he does nothing, that seems to me very poor project management indeed.
Linus is not a project manager.
Linus is not the sole copyright holder.
The other copyright holders are allowed to state their opinions.
If you dont like it, write your own OS...
There are good technical reasons for there not being a driver 'ABI' for Linux. Reason #1 is that even the source 'API' is not set in stone (so the ABI has/0/ chance), to be able to update interfaces when needed rather than leaving bad interfaces in place for the sake of compatibility can be a good thing.
Finally: You are no more required to use Linux and its horrid lack of "binary driver support" than the authors of Linux are required to provide it to you. You didnt pay them, you didn't the write the code, they did, they get to decide.
When you strike something out, be sure to date and sign (if even just with your initials) in the margin beside the lines struck out. Also, make sure to do this in *both* copies (ie dont forgot your own copy.).
That's what I do, and I've never had anyone come back to me. Trying to *talk* to HR people about getting contract clauses changed gets you nowhere 9/10, however given these HR people never seem to quibble about strike-outs or maybe even don't bother to read the contract before signing it for the company and filing it, this is the by far the easiest way to deal with silly clauses.
The BBC is not state controlled! It is a chartered, independent, publically funded body. The BBC's prime responsibility is to the UK public (not to the UK government, not to some media mogul). And the organisations' news division have a history of critical examination of the UK government.
I don't pay a british licence fee, but I *wish* I could (if it would allow to me access their digital satellite transmissions. It's encrypted but access is free to UK residents - which I'm not.).
M$-Windows server revenue was US$4.6 billion in 2004.
No, the windows/unix figures were for the last quarter of 2004, quoting the article:
Unix server revenue was $5.2 billion in the fourth quarter of 2004 while the corresponding figure for Windows was $4.6 billion.
Multiply by 4 to get ~$25G for Unix, $18G for Windows. So that puts Linux at somewhere around 1/4 of MS Windows. It also explains the "missing $34G" the other poster referred to. It isnt missing, 25+18+4.4 = 47.4G, so non-Windows/Unix/Linux revenue is somewhere between $1G to $2G.
My post was modded "informative" because I actually play with BIOS's.
Good for you. I've played with them too.
Because you've hand-waved away the BIOS level reporting into "ACPI does that for you"
I didn't say that, I said: "The PC BIOS most important function, [other than IPL], is to properly describe the hardware (IOW ACPI).". With emphasis on describe. And it's really funny you should pick on ACPI, because the raison d'etre of ACPI was precisely to runtime remove involvement of BIOS in hardware management, and make BIOS just hand-off the needed descriptive data at boot to the OS to allow the OS to do the runtime management, via the OS's own ACPI interpreter.
The ACPI data is to an extent a mostly static blob of data in the BIOS ROM. The BIOSes job wrt ACPI is to adjust/tweak this template at *boot* and then hand it to the OS, whose own interpreter will be doing the heavy lifting during runtime - no BIOS involed.
(such as setting boot-on-power-failure behavior, setting boot device orders, enabling serial console, hard-coding IRQ's and other stuff I do at least once a month)
Playing with the setup menu is something you consider low level stuff? And you feel qualified to tell slashdot how important the BIOS is and, more to the point, why?;)
You're simply describing settings in the CMOS data affecting initial setup and bootstrap - irrelevant after OS is booted. You can even manipulate these settings from within your OS quite easily (if you know which bits in the CMOS do what, you can figure that out reasonably easily enough if you want.).
A lot of ACPI functionality is deduced guesswork:
ROFL. ACPI is a published, documented specification by Intel. (It's a rather huge set of specs, but it's documented none the less. The Linux ACPI interpreter is actually written and maintained by Intel staffers.). BIOS vendors often manage to screw up the ACPI data, however the beauty (relatively seen, at least, in context of PC firmware) of ACPI is you can decompile that, fix it and override it if you want. See the Linux ACPI site.
open source BIOS would remove a huge amount of the guesswork and make the code controllable and reparable.
I agree. Though, not because of ACPI (for which open source interpreters *already* exist. ACPI data is machine dependent and requires proper specs for hardware, slightly orthogonal to open source BIOS).
but for some reason, on the old (AMD 32) laptop, most of it was handled by a curses (?) base program running in a dtterm.
Amount of memory most likely. The installer decides which to fire up based on RAM. Below X MB (I think 128, I cant remember) you get the text-install-in-dtterm-in-X. Below 64MB (iirc) you get text install from console - no X.
I dont remember the precise MB figures, unfortunately. The 'switch points' could be 256MB and 128MB respectively, rather than 128/64, I dont quite remember.
Other than boot and (maybe) shutdown, sure. It used to for suspend/resume, but no longer thanks to ACPI.
enabliing multiple CPU's
Nope. SMP PCs (and most SMP computers??) boot on one CPU. OS is responsible for booting other CPUs. (though, this may depend on BIOS having properly described them, it also obviously requires a hardware facility to allow OS to kick a CPU into running.).
managing the interrupts
Nope, that'd be your OS 9/10. Some computers do have a facility to allow firmware to trap certain interrupts/events (eg SMM on PCs I think) - but it should be rare.
affecting reboot behavior
In the case of Linux, try kexec - reboot linux directly from linux;).
manipulating power-on or sleep or suspend behavior
Nope, given everything is ACPI these days (BIOS callback into APM facilities being deprecated), that'd be the ACPI AML interpreter in your OS twiddling the relevant bits (based on ACPI information provided at boot by BIOS).
turning down the CPU clock when things over-heat
Other than for emergency use, no that'd be cpufreqd or acpid or similar responding to heat changes based on data gathered via OS drivers and effecting action again via OS drivers. In the emergency case (eg due to fan failure, or due to aforementioned daemons not doing their job on a marginal system) then yes that'd be firmware responding via aforementioned SMM (or SMM like) facilities.
reporting the temperature, reporting the CPU voltages, and everything else you need to know at the basic hardware levels.
Nope, that'd be the driver in your OS for your hardware monitoring chip (see linux lm-sensors), which are accessed via very simple serial bus.
About the only way your post could be classed as "informative" is if it were 20 years ago and the concept of OS was restricted to MS-DOS (BIOS doing most of the hardware work) or OS-in-firmware computers like original Apple IIs and Macintosh. These days the role of the PC BIOS for run-time thankfully has been almost eliminated. The PC BIOS most important function, other than initial hardware setup and initial programme load (IPL), is to properly describe the hardware (IOW ACPI). After IPL (i'll fudge and classify grub/lilo/$whatever-second-stage-loader making BIOS calls as part of IPL) it's your OS and only your OS running, other than for (hopefully) rare SMM traps.
How did you manage to be moderated informative? My mind is boggling so much i'm starting to feel dizzy...
That crash was due to pilot error, it had nothing to do with any "computer override" - indeed, the pilot had had to switch off several safety systems to make the flypast - that was a theory that was quickly discounted by the investigation. Please read a previous slashdot post of mine where I rebutted a previous occurance of this myth, along with a link to an excellent post to safety critical on this AirBus crash.
The computers were fine. It was pilot error, compounded several times over.
See my reply to e40. x86-64 can run both long mode 64bit apps and 32bit processes at same time, no problem. Solaris10 on x86-64 is just like on UltraSPARC - 64bit kernel (x86-64). I'm not 100% clear on the userspace, I'd have to poke around on an opteron box:), but I presume it's mostly x86 32bit, plus lib64's as it is on UltraSPARC. I'll try check this for you later and get exact first hand details (alternatively, just download S10 and install for yourself.)
Anyway, the kernel is *definitely* x86-64 on AMD64 by default, even if i'm not 100% certain of the userspace details (which i'm still reasonably certain runs both x86 and x86-64).
That's s10_72 on a non-AMD64 box (I'd login into an opteron S10 machine, but that box above happend to be to hand), which is the build used in Solaris Express in november. So the AMD64 support is there for a while now. As others have noted, the Solaris install is done with a 32bit kernel.
Re:Solaris 10 on Sun Ultra 5/Ultra 10 questions
on
Solaris 10 Released
·
· Score: 1
It should run fine.
I used S10 on a 128MB Ultra10 for a few weeks and it was fine. S10's GNOME2 JDS actually seems to run ok on low memory machines. More RAM always helps though;)
--paulj
Re:Solaris for Opteron? That's nice
on
Solaris 10 Released
·
· Score: 2, Interesting
The initial release of Solaris 10 is 32-bit only on x86, so you'll have to wait for release of a later version.
This isn't. AMD64 support was integrated into Solaris Express late last year. The same OS covers both IA32 and AMD64, just as how Solaris 9 on UltraSPARC supported both 32bit and 64bit machines. Solaris has been doing multi-ABI support transparently on UltraSPARC for quite a while now, and it transfers nicely to S10.
This is actually one area where Linux distributions lag behind Solaris. I dont know of any distributions which handle x86/x86-64 multi-ABI support cleanly. Debian is a pure x86-64 port, with chroot hacks to install and run x86 libs+binaries (apt doesnt do multi-abi very well yet). Fedora x86-64 tries to do multi-lib, but gets it wrong in places too, least FC2 hadnt fully split packages up for x86-64/noarch/x86 and it was far too easy to get conflicting installs of files from x86_64 and x86 packages.
I can't answer this, except to say that it's been Suns' stated intention to open Solaris up and this is simply the first opening of code as the whole of Solaris is opened up.
2. It seems very similar to gdb in role. Is this assumption correct? Does it compare favorably?
It's orthogonal to gdb. gdb is a debugger, to debug code. DTrace is a kernel instrumentation framework, allowing dynamic instrumentation of a fully running kernel (including interaction with userspace programmes).
3. Is a Linux/BSD/whatever port of this desirable/attainable? Or does it rely to much on the guts of SunOS? Do we have better tools already on those OS's?
A Linux/BSD "port" would be desireable in so far as DTrace is desireable (which would be "lots" imho). The guts of it is in-kernel though and kernel-specific, so it'd be mostly new work, but you could reuse the tools interface (the awk-like syntax). Linux has something vaguely similar called "kprobes", which I dont know that much about, except that it requires one to write kernel modules to make effective use of it - it doesnt have a nice, safe, userspace scripting language to specify how you want to collect data from the kernel instrumentation "probes", AFAICT.
Turns out that the guy was flying through fog and just must not have trusted his altimeter or artificial horizon, driving his plane at 'climb' speeds into a forest.
This happens all the time. VFR pilots who fly into cloud, become disorientated and then simply refuse to believe their instruments, and end up flying straight into ground or else straight up until they stall and dive into the ground. Iirc, this was the explanation for Kennedy's crash. I'm not sure, but I'll bet this accounts for a large number of crashes amongst non-IFR trained pilots.
But some of the commandments are certainly not for everyone, namely the one about worshipping false gods. That one pretty much excludes any other religion.
Not really.
God, Allah, Jehovah are all the same god. Jews, Christians and Muslims all worship the same "one" - hasnt stopped us killing each other in the name of that god though.;)
God created this world. It's arrogance and ignorance of the highest degree for men to say they understand how He did it.
Rubbish, if God created this world and all in it, there is nothing to say he did not also give man the ability to slowly figure out/how/ God created the universe. (Whether or not God, or Gods, exist and if so whether he or they or it created the universe is another question..).
Also, science does not claim to understand everything. If we understood everything, we'd have no need for science, as science is about the process of gaining understanding about the world about us. We likely never will have all the answers.
I'm talking about those who don't even want to look at the world God created for clues about how He did it before declaring that they know how the world works because of literalist interpetations of the bible.
Looking at the world, then trying to explain how it works, then seeing if the explanations hold up or need to be improved is exactly what science is about.
Personally, I wish those who take the bible so literally as to argue that creation according to Genesis trumps science would be as literal about their interpretation of "Thou shalt not kill", "Let he who is without sin cast the first stone" and "Do unto others as you would have them do unto you". The world would be a much better place if the bible thumpers would follow the morality taught by the new testament as literally.
Last time I checked iraqbodycount.net, it was between 15k and 17k.
Iraqbodycount.net counts confirmed civilian deaths reported by multiple sources. It's the "absolutely no doubt" lower floor-limit of deaths, as they state on their own site, their figure is a sample of the number of confirmed deaths in Iraq. Quite useful figure, but remember what it is.
And but I have noticed that they include Iraqis killed by attacks from insurgents in those counts, and I don't agree with that.
Feel free. But those deaths wouldnt have occured under Saddam. In the same vein, be sure to exclude casualties arising from the Iran-Iraq war from the "Deaths under Saddam" figure (wouldnt have occurred without western encouragement).
the 100k number comes from the Lancet study that was discredited almost immediately after release.
Misinterpreted, yes, in both directions. Critiqued too. I dont remember discredited though.
They relied on a flawed methodology to collect their data,
The methodology was not ideal, but the situation in Iraq makes it very difficult. As you point out, their confidence interval was very broad as a result. The report itself discusses limitations in the methodology btw. Further, the Fallujah cluster was excluded from the results because it was felt not to representative of Iraq - with Fallujah included the figures are higher.
even with that their margin of error with 95% confidence was +/- 98,000.
Yep.
So they were only able to say that they were 95% sure that there were between 2,000 and 200,000 casualties- not a very strong analysis.
It's a confidence level. Further, your memory is wrong, it was 0.95 probability that the true figure lay between 8k and 194k. This is a confidence level which reflects on the statistical probability btw, it doesnt mean that 8,000 deaths is a probable # of deaths. It simply means 8,000 deaths is as probable as 200,000 - and both lie at the very extremities of probability. But it *is* a useful indication that mortality since the conflict probably lies between around 50 to 140k deaths. (Again, the lower and upper of those figures are at same probability - according to this survey, and they are far more probably than 2k or 200k, though the confidence level for that interval would be lower, obviously).
Essentially, it's unlikely that Iraq is a safer place now than it was under Saddam. It's quite likely it's just as dangerous, reasonably likely that it is more dangerous, possibly even far more dangerous.
I'm not trying to make any judgement about the intentions of the US in the Iraq conflict, or it's responsibilities, I'm just commenting on the change it has wrought on Iraq. Some will view the present instability and danger as a worthwhile ill to get Iraq towards a safe, peaceful democracy. Only time and history will tell whether that view will be borne out.
Slashdot Mirror
Not proprietary, but NetBSD, Linux and (iirc) OpenBSD all run fine on sparc64. Indeed, I have a vague notion Sun gave David Miller access to some big Sparc64 machines to help test Linux Sparc64 on big SMP Sparc64 boxes (but i could be wrong).
Plain and simple, because they fear competition. By being GPL, it allows others to benefit from their work (and work that they received from others). By going with CDDL, only they become the all inclusive taker. It is similar to the MS shared source. But unlike MS, when SUN's shares start sinking (and they will), Sun will move over to the GPL, still have a losing market and then state that GPL does not work.
/. and other "open source" community sites. If the Sun-haters were to have their way and see Sun fail then a good[1] number of open-source hackers would be out of work (including myself).
Rubbish. As already described several times on the blogs of important Sun people, they considered the GPL quite seriously, but found it wasn't suitable. One obvious reason is that the GPL is slightly too restrictive for OpenSolaris - not all hardware vendors want to have to release source, which coding to a GPL'd driver interface would almost certainly require. The CDDL allows ISVs to decide for themselves whether to open their code or not. Sun wrote and/or own Solaris, Sun wanted to allow others to be able to use it without having to release their modifications (remember, Sun has strong BSD roots), so Sun fixed the problems in the MPL to create the CDDL. Further, the GPL does not deal with the problem of patent litigation in any meaningful way (one of the goals for GPLv3 apparently is to do that - hopefully they'll draw from the CDDL approach to patents, which is quite nice.).
I fail to see how working towards releasing Solaris under a liberal licence such as the CDDL qualifies as trying to "hold on to a monopoly".
If you think this is bogus, consider that many many Linux users who are happy to bash the CDDL are using proprietary kernel drivers, particularly for graphics cards, which are in possibly in a grey legal area wrt GPL status of Linux - particularly the ATi drivers, which are (IIRC) based on DRI in some way (the NVidia drivers arent).
Note that Sun do not have a problem with the GPL. There are lots of GPL and LGPL projects out there whose ChangeLogs contain @sun.com addresses, eg GNOME and OpenOffice to name just two (Indeed, Sun bought out and then LGPL'd OpenOffice). And I'm very involved in a GPL project myself..
It's a real shame there is such anti-Sun hysteria on
Thanks.
1. And I dont include OpenSolaris hackers in that. Once OpenSolaris is out there, virtually every Sun engineer working on Solaris will be an open-source hacker too.
I think we [the U.S.] should institute weight/horsepower classes like they do for two-wheeled vehicles in Japan, but for all types of vehicles.
/all/ bikers, simply because of inexperienced bikers (who'd get into trouble regardless of the power of their bike), is a dumb idea.
;) ).
I did far dumber stuff, got into far more danger on a regular basis, had more crashes and broke more bones on my 50cc 3hp/70kg Kawa AR50 when I was a teenager than I ever did on my 250cc 60hp/140kg RS250 as young twenty-something. Even that pathetic 50cc AR50 can get up to 85km/h, which is more than enough to get badly hurt.
It comes down not to power/weight ratio, but to *experience*. Indeed, the higher risks insurers of motorcycles in this country have is of the small *low power* motorcycles, because small low-power bikes tend to be ridden by new riders. Some of the other high-risk categories are "new age bikers", middle aged men who return to motorcycles and can afford the insurance on big bikes, but its their inexperience which kills them, not the power of the bike - they'd likely have had the same accident on a low-power bike.
Inexperience will get you hurt on a motorcycle, low or high power regardless. However, decent power can be a good thing, an aide to safety: it gives you a last-resort option which you dont have on a tweeny bike, the power to possibly get out of trouble really quickly with a twist of the wrist. Removing this option from
(plus, 0 to 100km/h in 4s is simply good fun
Hmm.. it's a great spin on the fact that there's neither the political will nor the appetite to paw over the kernel device driver interface and create a full, strict, detailed and fully thought out interface document to which the kernel and device drivers can be written and verified against and have it imposed on the kernel and driver developers.
But there's the problem in a nutshell "imposed on the kernel and driver developers", who, pray tell, is going to do that? Further, from a resource allocation point of view, if one could "impose" in such a way on the kernel developers, is it a good idea to divert resources away from hacking on other things and onto designing, implementing and sustaining to-be-set-in-stone driver interfaces? And once that's done and a problem is found in the interface (which will always occur), what do you do then?
Maintaining guaranteed ABIs for significant periods of time can be very very difficult and resource consuming, hence not everyone cares to take the time to do it. For Linux, where the vast bulk of drivers are maintained in the kernel, by the kernel people, alongside the rest of the core kernel code, it doesn't make sense to spend time guaranteeing interfaces for a very few 3rd party drivers. Note that there are other kernels which do provide such ABI stability for 3rd party drivers. You are quite free to use them.
Or find a Linux distro maker who you can pay to support binary drivers. If so many Linux users think it is so needed, I'm sure someone would be willing to take your Euro's to provide it...
In short, your choices are:
- lobby your vendor for open-drivers and/or programming specifications for your hardware (cause then it can be integrated into Linux kernel, the kernel people will help maintain it, and other kernel's can benefit from having source/docs to look at to help implement their own drivers).
- Put your money (collectively or not) where your mouth is and pay someone to take care of this, obviously highly critical, missing functionality.
- Go use a different system which does provide this highly critical functionality you need.
or finally:
- Continue using Linux and stop whinging
I would like to see Linux succeed. However, the way it's going at the moment I can see it becoming an interesting footnote in history.
Wow, Linux is dying!!! That's a new one on slashdot.
He may not manage them in the traditional sense of the word, but when they are making statements to driver developers that flatly contradict Linus' official policy and he does nothing, that seems to me very poor project management indeed.
/0/ chance), to be able to update interfaces when needed rather than leaving bad interfaces in place for the sake of compatibility can be a good thing.
Linus is not a project manager.
Linus is not the sole copyright holder.
The other copyright holders are allowed to state their opinions.
If you dont like it, write your own OS...
There are good technical reasons for there not being a driver 'ABI' for Linux. Reason #1 is that even the source 'API' is not set in stone (so the ABI has
Finally: You are no more required to use Linux and its horrid lack of "binary driver support" than the authors of Linux are required to provide it to you. You didnt pay them, you didn't the write the code, they did, they get to decide.
When you strike something out, be sure to date and sign (if even just with your initials) in the margin beside the lines struck out. Also, make sure to do this in *both* copies (ie dont forgot your own copy.).
That's what I do, and I've never had anyone come back to me. Trying to *talk* to HR people about getting contract clauses changed gets you nowhere 9/10, however given these HR people never seem to quibble about strike-outs or maybe even don't bother to read the contract before signing it for the company and filing it, this is the by far the easiest way to deal with silly clauses.
--paulj
state controlled TV network
The BBC is not state controlled! It is a chartered, independent , publically funded body. The BBC's prime responsibility is to the UK public (not to the UK government, not to some media mogul). And the organisations' news division have a history of critical examination of the UK government.
I don't pay a british licence fee, but I *wish* I could (if it would allow to me access their digital satellite transmissions. It's encrypted but access is free to UK residents - which I'm not.).
M$-Windows server revenue was US$4.6 billion in 2004.
No, the windows/unix figures were for the last quarter of 2004, quoting the article:
Unix server revenue was $5.2 billion in the fourth quarter of 2004 while the corresponding figure for Windows was $4.6 billion.
Multiply by 4 to get ~$25G for Unix, $18G for Windows. So that puts Linux at somewhere around 1/4 of MS Windows. It also explains the "missing $34G" the other poster referred to. It isnt missing, 25+18+4.4 = 47.4G, so non-Windows/Unix/Linux revenue is somewhere between $1G to $2G.
My post was modded "informative" because I actually play with BIOS's.
;)
Good for you. I've played with them too.
Because you've hand-waved away the BIOS level reporting into "ACPI does that for you"
I didn't say that, I said: "The PC BIOS most important function, [other than IPL], is to properly describe the hardware (IOW ACPI).". With emphasis on describe. And it's really funny you should pick on ACPI, because the raison d'etre of ACPI was precisely to runtime remove involvement of BIOS in hardware management, and make BIOS just hand-off the needed descriptive data at boot to the OS to allow the OS to do the runtime management, via the OS's own ACPI interpreter.
The ACPI data is to an extent a mostly static blob of data in the BIOS ROM. The BIOSes job wrt ACPI is to adjust/tweak this template at *boot* and then hand it to the OS, whose own interpreter will be doing the heavy lifting during runtime - no BIOS involed.
(such as setting boot-on-power-failure behavior, setting boot device orders, enabling serial console, hard-coding IRQ's and other stuff I do at least once a month)
Playing with the setup menu is something you consider low level stuff? And you feel qualified to tell slashdot how important the BIOS is and, more to the point, why?
You're simply describing settings in the CMOS data affecting initial setup and bootstrap - irrelevant after OS is booted. You can even manipulate these settings from within your OS quite easily (if you know which bits in the CMOS do what, you can figure that out reasonably easily enough if you want.).
A lot of ACPI functionality is deduced guesswork:
ROFL. ACPI is a published, documented specification by Intel. (It's a rather huge set of specs, but it's documented none the less. The Linux ACPI interpreter is actually written and maintained by Intel staffers.). BIOS vendors often manage to screw up the ACPI data, however the beauty (relatively seen, at least, in context of PC firmware) of ACPI is you can decompile that, fix it and override it if you want. See the Linux ACPI site.
open source BIOS would remove a huge amount of the guesswork and make the code controllable and reparable.
I agree. Though, not because of ACPI (for which open source interpreters *already* exist. ACPI data is machine dependent and requires proper specs for hardware, slightly orthogonal to open source BIOS).
but for some reason, on the old (AMD 32) laptop, most of it was handled by a curses (?) base program running in a dtterm.
Amount of memory most likely. The installer decides which to fire up based on RAM. Below X MB (I think 128, I cant remember) you get the text-install-in-dtterm-in-X. Below 64MB (iirc) you get text install from console - no X.
I dont remember the precise MB figures, unfortunately. The 'switch points' could be 256MB and 128MB respectively, rather than 128/64, I dont quite remember.
Your post wasn't much better, in fact it is worse because it implies that the bios doesn't control anything important.
So what exactly does it control then?
How about System Management Mode, for one thing.
System Management Mode -> SMM, I mentioned SMM at least twice in my post to which you replied.
Except turning on and off the hardware,
;).
Other than boot and (maybe) shutdown, sure. It used to for suspend/resume, but no longer thanks to ACPI.
enabliing multiple CPU's
Nope. SMP PCs (and most SMP computers??) boot on one CPU. OS is responsible for booting other CPUs. (though, this may depend on BIOS having properly described them, it also obviously requires a hardware facility to allow OS to kick a CPU into running.).
managing the interrupts
Nope, that'd be your OS 9/10. Some computers do have a facility to allow firmware to trap certain interrupts/events (eg SMM on PCs I think) - but it should be rare.
affecting reboot behavior
In the case of Linux, try kexec - reboot linux directly from linux
manipulating power-on or sleep or suspend behavior
Nope, given everything is ACPI these days (BIOS callback into APM facilities being deprecated), that'd be the ACPI AML interpreter in your OS twiddling the relevant bits (based on ACPI information provided at boot by BIOS).
turning down the CPU clock when things over-heat
Other than for emergency use, no that'd be cpufreqd or acpid or similar responding to heat changes based on data gathered via OS drivers and effecting action again via OS drivers. In the emergency case (eg due to fan failure, or due to aforementioned daemons not doing their job on a marginal system) then yes that'd be firmware responding via aforementioned SMM (or SMM like) facilities.
reporting the temperature, reporting the CPU voltages, and everything else you need to know at the basic hardware levels.
Nope, that'd be the driver in your OS for your hardware monitoring chip (see linux lm-sensors), which are accessed via very simple serial bus.
About the only way your post could be classed as "informative" is if it were 20 years ago and the concept of OS was restricted to MS-DOS (BIOS doing most of the hardware work) or OS-in-firmware computers like original Apple IIs and Macintosh. These days the role of the PC BIOS for run-time thankfully has been almost eliminated. The PC BIOS most important function, other than initial hardware setup and initial programme load (IPL), is to properly describe the hardware (IOW ACPI). After IPL (i'll fudge and classify grub/lilo/$whatever-second-stage-loader making BIOS calls as part of IPL) it's your OS and only your OS running, other than for (hopefully) rare SMM traps.
How did you manage to be moderated informative? My mind is boggling so much i'm starting to feel dizzy...
That crash was due to pilot error, it had nothing to do with any "computer override" - indeed, the pilot had had to switch off several safety systems to make the flypast - that was a theory that was quickly discounted by the investigation. Please read a previous slashdot post of mine where I rebutted a previous occurance of this myth, along with a link to an excellent post to safety critical on this AirBus crash.
The computers were fine. It was pilot error, compounded several times over.
See my reply to e40. x86-64 can run both long mode 64bit apps and 32bit processes at same time, no problem. Solaris10 on x86-64 is just like on UltraSPARC - 64bit kernel (x86-64). I'm not 100% clear on the userspace, I'd have to poke around on an opteron box :), but I presume it's mostly x86 32bit, plus lib64's as it is on UltraSPARC. I'll try check this for you later and get exact first hand details (alternatively, just download S10 and install for yourself.)
Anyway, the kernel is *definitely* x86-64 on AMD64 by default, even if i'm not 100% certain of the userspace details (which i'm still reasonably certain runs both x86 and x86-64).
bash-2.05b# uname -a
SunOS xxxxxx 5.10 s10_72 i86pc i386 i86pc
bash-2.05b# ls
amd64 dacf dtrace fs ipp mach sched sys
crypto drv exec genunix kmdb misc strmod
bash-2.05b# ls
genunix
That's s10_72 on a non-AMD64 box (I'd login into an opteron S10 machine, but that box above happend to be to hand), which is the build used in Solaris Express in november. So the AMD64 support is there for a while now. As others have noted, the Solaris install is done with a 32bit kernel.
It should run fine.
;)
I used S10 on a 128MB Ultra10 for a few weeks and it was fine. S10's GNOME2 JDS actually seems to run ok on low memory machines. More RAM always helps though
--paulj
The initial release of Solaris 10 is 32-bit only on x86, so you'll have to wait for release of a later version.
This isn't. AMD64 support was integrated into Solaris Express late last year. The same OS covers both IA32 and AMD64, just as how Solaris 9 on UltraSPARC supported both 32bit and 64bit machines. Solaris has been doing multi-ABI support transparently on UltraSPARC for quite a while now, and it transfers nicely to S10.
This is actually one area where Linux distributions lag behind Solaris. I dont know of any distributions which handle x86/x86-64 multi-ABI support cleanly. Debian is a pure x86-64 port, with chroot hacks to install and run x86 libs+binaries (apt doesnt do multi-abi very well yet). Fedora x86-64 tries to do multi-lib, but gets it wrong in places too, least FC2 hadnt fully split packages up for x86-64/noarch/x86 and it was far too easy to get conflicting installs of files from x86_64 and x86 packages.
1. Why has Sun open sourced this of all things?
I can't answer this, except to say that it's been Suns' stated intention to open Solaris up and this is simply the first opening of code as the whole of Solaris is opened up.
2. It seems very similar to gdb in role. Is this assumption correct? Does it compare favorably?
It's orthogonal to gdb. gdb is a debugger, to debug code. DTrace is a kernel instrumentation framework, allowing dynamic instrumentation of a fully running kernel (including interaction with userspace programmes).
3. Is a Linux/BSD/whatever port of this desirable/attainable? Or does it rely to much on the guts of SunOS? Do we have better tools already on those OS's?
A Linux/BSD "port" would be desireable in so far as DTrace is desireable (which would be "lots" imho). The guts of it is in-kernel though and kernel-specific, so it'd be mostly new work, but you could reuse the tools interface (the awk-like syntax). Linux has something vaguely similar called "kprobes", which I dont know that much about, except that it requires one to write kernel modules to make effective use of it - it doesnt have a nice, safe, userspace scripting language to specify how you want to collect data from the kernel instrumentation "probes", AFAICT.
Turns out that the guy was flying through fog and just must not have trusted his altimeter or artificial horizon, driving his plane at 'climb' speeds into a forest.
This happens all the time. VFR pilots who fly into cloud, become disorientated and then simply refuse to believe their instruments, and end up flying straight into ground or else straight up until they stall and dive into the ground. Iirc, this was the explanation for Kennedy's crash. I'm not sure, but I'll bet this accounts for a large number of crashes amongst non-IFR trained pilots.
if you want a "guaranteed" investment - an investment that'll do at least as well as Social Security - why not just invest in US Treasuries?
What do you think Social Security is invested in? RTFA.
Imagine the poors sods at the FBI who have to wade all through the spam! :)
;)
Actually, there's a thought on how to avoid FBI monitoring - just disguise your message as spam.
It's like you read my post, then managed to completely misunderstand it.
Here goes the cliffs notes version:
Ah, I did indeed completely misunderstand you. Thanks for the clarification.
But some of the commandments are certainly not for everyone, namely the one about worshipping false gods. That one pretty much excludes any other religion.
;)
Not really.
God, Allah, Jehovah are all the same god. Jews, Christians and Muslims all worship the same "one" - hasnt stopped us killing each other in the name of that god though.
God created this world. It's arrogance and ignorance of the highest degree for men to say they understand how He did it.
/how/ God created the universe. (Whether or not God, or Gods, exist and if so whether he or they or it created the universe is another question..).
Rubbish, if God created this world and all in it, there is nothing to say he did not also give man the ability to slowly figure out
Also, science does not claim to understand everything. If we understood everything, we'd have no need for science, as science is about the process of gaining understanding about the world about us. We likely never will have all the answers.
I'm talking about those who don't even want to look at the world God created for clues about how He did it before declaring that they know how the world works because of literalist interpetations of the bible.
Looking at the world, then trying to explain how it works, then seeing if the explanations hold up or need to be improved is exactly what science is about.
Personally, I wish those who take the bible so literally as to argue that creation according to Genesis trumps science would be as literal about their interpretation of "Thou shalt not kill", "Let he who is without sin cast the first stone" and "Do unto others as you would have them do unto you". The world would be a much better place if the bible thumpers would follow the morality taught by the new testament as literally.
No it isn't.
Yes, it pretty much is, sadly.
Last time I checked iraqbodycount.net, it was between 15k and 17k.
Iraqbodycount.net counts confirmed civilian deaths reported by multiple sources. It's the "absolutely no doubt" lower floor-limit of deaths, as they state on their own site, their figure is a sample of the number of confirmed deaths in Iraq. Quite useful figure, but remember what it is.
And but I have noticed that they include Iraqis killed by attacks from insurgents in those counts, and I don't agree with that.
Feel free. But those deaths wouldnt have occured under Saddam. In the same vein, be sure to exclude casualties arising from the Iran-Iraq war from the "Deaths under Saddam" figure (wouldnt have occurred without western encouragement).
the 100k number comes from the Lancet study that was discredited almost immediately after release.
Misinterpreted, yes, in both directions. Critiqued too. I dont remember discredited though.
They relied on a flawed methodology to collect their data,
The methodology was not ideal, but the situation in Iraq makes it very difficult. As you point out, their confidence interval was very broad as a result. The report itself discusses limitations in the methodology btw. Further, the Fallujah cluster was excluded from the results because it was felt not to representative of Iraq - with Fallujah included the figures are higher.
even with that their margin of error with 95% confidence was +/- 98,000.
Yep.
So they were only able to say that they were 95% sure that there were between 2,000 and 200,000 casualties- not a very strong analysis.
It's a confidence level. Further, your memory is wrong, it was 0.95 probability that the true figure lay between 8k and 194k. This is a confidence level which reflects on the statistical probability btw, it doesnt mean that 8,000 deaths is a probable # of deaths. It simply means 8,000 deaths is as probable as 200,000 - and both lie at the very extremities of probability. But it *is* a useful indication that mortality since the conflict probably lies between around 50 to 140k deaths. (Again, the lower and upper of those figures are at same probability - according to this survey, and they are far more probably than 2k or 200k, though the confidence level for that interval would be lower, obviously).
Essentially, it's unlikely that Iraq is a safer place now than it was under Saddam. It's quite likely it's just as dangerous, reasonably likely that it is more dangerous, possibly even far more dangerous.
I'm not trying to make any judgement about the intentions of the US in the Iraq conflict, or it's responsibilities, I'm just commenting on the change it has wrought on Iraq. Some will view the present instability and danger as a worthwhile ill to get Iraq towards a safe, peaceful democracy. Only time and history will tell whether that view will be borne out.