AMD made their platform code work for coreboot. That is, the same code they ship to board and BIOS makers, they release to coreboot, and even went the extra mile to integrate it.
Intel doesn't support coreboot. In fact, they hinder us and we'll have to get each bit of information out of the hardware or by massive coercion. Every support of Intel hardware in coreboot exists despite Intel's efforts.
"corporations who see their employees as means to an end rather than the end itself" - Human resources are an expense not an asset, bringing in no value. At least from the bean counters' point of view.
That's why one of the first thing consultants (eunuchs: they know how to do it) recommend is to lay off employees - it's a "simple" step in cutting down a huge piece of the expenses with no value lost.
Intel delivers all of their boot support code as EFI drivers these days.
But not as open source. Tiano is a huge bunch of code, but the really interesting bits aren't in there.
EFI is much better than BIOS. It runs in full 32/64 bit mode.
coreboot welcomes you to 1999. Besides that: why is it that EFI exists in "either 32 or 64bit", instead of cleanly supporting both? The additional complexity of thunking libraries can't be it, as tiano already provides a runtime loader to resolve in-flash libraries...
Booting Intel machines is really fucking complicated, and EFI makes it much simpler.
Sorry, but EFI is fucking complicated, too. runtime linker - I rest my case. It's just that you don't have to care about this complexity when intel provides the closed source components to you to plug in.
The most reasonable action about EFI over the last few years was the EFI shell effort. Finally Intel admits that they designed an operating system instead of a hardware bringup.
OpenBIOS is used for some OpenFirmware platforms in QEmu mostly. It's partially obsoleted by three separate OpenFirmware implementations released under BSD-like licensing later-on, which had real world exposure (unlike OpenBIOS, which we wrote from scratch according to the specification).
On real (x86) hardware coreboot (www.coreboot.org) is a better match. It supports everything from special designs to "standard" systems: Linux, some custom loader, a pcbios implementation, or UEFI (or even OpenBIOS, if you so desire) running after hardware initialization, you're free to decide what to use. The main problem is that we struggle to keep up with all the new chipsets and CPUs.
That's 11 countries of geographic Europe, which covers 46 countries, so that's not "about half", but "less than a quarter".
Taking only the EU countries into account, your list of 11 shrinks to 5 (Russia, Ukraine, Belarus, Switzerland, Norway, and Serbia aren't part of the EU), while there are 27 EU countries (one of them, Cyprus, outside geographic Europe). That's less than a fifth.
SWT isn't as portable. it's also pretty quirky in behaviour, and doesn't seem very stable wrt API.
it also creates quite a lot of controls manually (see the tabbar in both azureus and eclipse).
also, people don't seem to have problems with windows toolbars and buttons, ms office toolbars and buttons (different ones), internet explorer toolbars and buttons (again, different ones), ms messenger toolbars and buttons (...) and windows media player toolbars and buttons (...) - not to speak of controls in non-microsoft applications (winamp, borland based apps,...)
that "help, that button looks different, where should I click" issue is a myth. swing had more problems due to its slow speed in the early versions, and that issue is fixed (unless you can't code, but that's true for any toolkit, GUI or not).
www.openbios.org - together with linuxbios we could make this work.. except that programming the lowlevel setup is non-trivial, because it's usually undocumented, and if you can get to documentation, under NDA or not, it tends to be bug-ridden in that area
IEEE1275-1994 is withdrawn because no-one cared to pay money for someone at IEEE to rubber stamp a changed year number (so it could become IEEE1275-1999 and then -2004).
it's still in active use on every PPC device and every SPARC device, necessary extensions (new busses etc) are handled via supplementals.
"it's Sun proprietary, licensed source code, covered by copyrights, patents, and trademarks."
- linux, xorg,.. is covered by copyrights (every software that isn't public domain stuff is). copyright is what makes the "free software" licenses work (esp. their restrictions), so it can't be all that bad, right? - patents related to java: care to demonstrate? any place where they used (or threatened to use) those (so far theoretical) patents to stop a competitor (be it a different java implementation or another language/vm/library or whatever else you can come up with)? anything that they _ever_ used a patent related to software aggressively or threatened to do so? - trademarks: "mozilla" and part of its artwork is trademarked, "linux" is a trademark,.. what's your point?
as for your little ad-hominem attack, just don't, 'mkay?
actually, the GPL is far from unique in that regard. basically, every OSI approved license works that way: it gives you rights you wouldn't have with only copyright law in effect.
in exchange it has a certain amount of obligations related to redistribution (GPL: share again, BSD: keep copyright notices, CDDL: tech you patented and used in this code is implicitely covered with a license to the recipient,...)
hmm.. "sun-built boxes", like that sun v20z are suspiciously similar to other boxes, eg. the newisys khepri 2100 (in this case)
also, solaris 10 runs fine on my non "sun-approved" machines (ie. designs built or reused by sun). a cpu is a cpu is a cpu, and support for everything else is catching up fast these days (also thanks to stable interfaces, which make binary drivers less painful)
yep, a rocket control system is cleanly designed and implemented (you better hope so, at least!), while SMB/CIFS grew over two decades with about 20 different implementations with partially different behaviour and the need to interoperate (all windows versions incl. some patch releases, OS/2,...)
still considerable german workforce and with a decade of history as a german company. and there's mandriva in france.. hm.. trolltech (norway) might be interested in some win32 protocols, too
and no, apart from SAP we don't have that many big software companies over here
the gimp devs probably have just as much inertia wrt UI knowledge as the photoshop users have with theirs.
so it's not "better or worse", it's "being used to or not"
of course, a solution might be an easily configurable GUI with several presets ("current GIMP" and "photoshop-alike" being two of them), but why should the gimp devs care (apart from finally getting rid of those annoying photoshop-kiddies - and procmail is still less effort)? but it might be a usable middle road *shrug*
Slashdot Mirror
AMD made their platform code work for coreboot. That is, the same code they ship to board and BIOS makers, they release to coreboot, and even went the extra mile to integrate it.
Intel doesn't support coreboot. In fact, they hinder us and we'll have to get each bit of information out of the hardware or by massive coercion. Every support of Intel hardware in coreboot exists despite Intel's efforts.
That issue has been debated and refuted before git even existed: http://www.monotone.ca/docs/Hash-Integrity.html
There's also venti of plan9 that uses SHA-1 for content addressing: http://en.wikipedia.org/wiki/Venti
But of course, they must be all wrong.
"corporations who see their employees as means to an end rather than the end itself" - Human resources are an expense not an asset, bringing in no value. At least from the bean counters' point of view.
That's why one of the first thing consultants (eunuchs: they know how to do it) recommend is to lay off employees - it's a "simple" step in cutting down a huge piece of the expenses with no value lost.
If they turn a profit on each kinect sold, then even those that are never attached to an xbox360 will help recoup R&D costs.
Intel delivers all of their boot support code as EFI drivers these days.
But not as open source. Tiano is a huge bunch of code, but the really interesting bits aren't in there.
EFI is much better than BIOS. It runs in full 32/64 bit mode.
coreboot welcomes you to 1999. Besides that: why is it that EFI exists in "either 32 or 64bit", instead of cleanly supporting both? The additional complexity of thunking libraries can't be it, as tiano already provides a runtime loader to resolve in-flash libraries...
Booting Intel machines is really fucking complicated, and EFI makes it much simpler.
Sorry, but EFI is fucking complicated, too. runtime linker - I rest my case.
It's just that you don't have to care about this complexity when intel provides the closed source components to you to plug in.
The most reasonable action about EFI over the last few years was the EFI shell effort. Finally Intel admits that they designed an operating system instead of a hardware bringup.
OpenBIOS is used for some OpenFirmware platforms in QEmu mostly.
It's partially obsoleted by three separate OpenFirmware implementations released under BSD-like licensing later-on, which had real world exposure (unlike OpenBIOS, which we wrote from scratch according to the specification).
On real (x86) hardware coreboot (www.coreboot.org) is a better match.
It supports everything from special designs to "standard" systems: Linux, some custom loader, a pcbios implementation, or UEFI (or even OpenBIOS, if you so desire) running after hardware initialization, you're free to decide what to use.
The main problem is that we struggle to keep up with all the new chipsets and CPUs.
That's 11 countries of geographic Europe, which covers 46 countries, so that's not "about half", but "less than a quarter".
Taking only the EU countries into account, your list of 11 shrinks to 5 (Russia, Ukraine, Belarus, Switzerland, Norway, and Serbia aren't part of the EU), while there are 27 EU countries (one of them, Cyprus, outside geographic Europe). That's less than a fifth.
he released the dvd code by now.
*yawn* _what_ do you think are we using alternating current for? we run on reversed polarity _all_ _the_ _time_.
SWT isn't as portable. it's also pretty quirky in behaviour, and doesn't seem very stable wrt API.
...)
it also creates quite a lot of controls manually (see the tabbar in both azureus and eclipse).
also, people don't seem to have problems with windows toolbars and buttons, ms office toolbars and buttons (different ones), internet explorer toolbars and buttons (again, different ones), ms messenger toolbars and buttons (...) and windows media player toolbars and buttons (...) - not to speak of controls in non-microsoft applications (winamp, borland based apps,
that "help, that button looks different, where should I click" issue is a myth. swing had more problems due to its slow speed in the early versions, and that issue is fixed (unless you can't code, but that's true for any toolkit, GUI or not).
opensolaris was announced less than 50 days ago, and the process of open sourcing isn't even finished yet.
what do you expect?
as for solaris, 2 mio downloads in 6 months are pretty impressive in my opinion (and yes, you can resume broken downloads in sun's download system)
we wrote the virtual machine in C - still small, and it's less maintenance that way
www.openbios.org
OpenFirmware is SUNs brainchild, IBM (and Apple) adopted it in the powerpc development process
www.openbios.org - together with linuxbios we could make this work..
except that programming the lowlevel setup is non-trivial, because it's usually undocumented, and if you can get to documentation, under NDA or not, it tends to be bug-ridden in that area
the idea is to do the same thing as now, just portably: provide the driver on the option rom that can be put onto the device
openfirmware does it this way since 1994
IEEE1275-1994 is withdrawn because no-one cared to pay money for someone at IEEE to rubber stamp a changed year number (so it could become IEEE1275-1999 and then -2004).
it's still in active use on every PPC device and every SPARC device, necessary extensions (new busses etc) are handled via supplementals.
well, OF exists for 1994 - so intel should have joined the OF effort (IEEE standard, even)
they didn't.. and defined a standard 10 times larger than OF, doing approximately the same
if we (the OF people) join them, the best that could happen is a combined standard 11 times larger than OF - not wise.
all well and known.. vnc aims for a different target.
try X11 (or it's spin-off NX) for a real RDC comparison
"it's Sun proprietary, licensed source code, covered by copyrights, patents, and trademarks."
.. is covered by copyrights (every software that isn't public domain stuff is). copyright is what makes the "free software" licenses work (esp. their restrictions), so it can't be all that bad, right? .. what's your point?
- linux, xorg,
- patents related to java: care to demonstrate? any place where they used (or threatened to use) those (so far theoretical) patents to stop a competitor (be it a different java implementation or another language/vm/library or whatever else you can come up with)? anything that they _ever_ used a patent related to software aggressively or threatened to do so?
- trademarks: "mozilla" and part of its artwork is trademarked, "linux" is a trademark,
as for your little ad-hominem attack, just don't, 'mkay?
actually, the GPL is far from unique in that regard. basically, every OSI approved license works that way: it gives you rights you wouldn't have with only copyright law in effect.
...)
in exchange it has a certain amount of obligations related to redistribution (GPL: share again, BSD: keep copyright notices, CDDL: tech you patented and used in this code is implicitely covered with a license to the recipient,
hmm.. "sun-built boxes", like that sun v20z are suspiciously similar to other boxes, eg. the newisys khepri 2100 (in this case)
also, solaris 10 runs fine on my non "sun-approved" machines (ie. designs built or reused by sun).
a cpu is a cpu is a cpu, and support for everything else is catching up fast these days (also thanks to stable interfaces, which make binary drivers less painful)
it seems to be as standardized as MPEG: you can get the docs, you even get a reference implementation. probably even for free
but each distributed unit and each streamed minute of media costs money
yep, a rocket control system is cleanly designed and implemented (you better hope so, at least!), while SMB/CIFS grew over two decades with about 20 different implementations with partially different behaviour and the need to interoperate (all windows versions incl. some patch releases, OS/2, ...)
things get _terribly_ messy that way
still considerable german workforce and with a decade of history as a german company.
and there's mandriva in france..
hm.. trolltech (norway) might be interested in some win32 protocols, too
and no, apart from SAP we don't have that many big software companies over here
the gimp devs probably have just as much inertia wrt UI knowledge as the photoshop users have with theirs.
so it's not "better or worse", it's "being used to or not"
of course, a solution might be an easily configurable GUI with several presets ("current GIMP" and "photoshop-alike" being two of them), but why should the gimp devs care (apart from finally getting rid of those annoying photoshop-kiddies - and procmail is still less effort)?
but it might be a usable middle road *shrug*