Fancy you quote the MS Windows kernel as a shining example of having a wonderful reputation for stability and security.
Malicious allegations aside, just the ability to hide away sloppy work has created a nightmare.
You do not specify exactly which kernels from IBM, HP you have in mind, but if you speak of their unices, at least their ancestors were in the open, the academic, or at least licensed/known to a lot of people for a long time, and they have not exactly prospered and advanced a whole lot recently.
Whoever tries 1) or 2) of this will learn one thing fast: when installing packages from out of your own distro or closely associated providers, regardless of package format, those package severely lack integration.
The ISO standard is doomed for the same reason LSB hasn't really taken off. Sure, a package might install, but to make it useable and interact with the rest of your system much more than this is neccessary. The slow (and usually thorough) pace of ISO will make any standard it produces in the field of fast paced distro development stale the day it comes out. Never mind the complexity of the task is on the order of managing several distros at once, blindfolded, while producing pretty Powerpoint presentations for the comittee.
If you really need something not available in Debian/Ubuntu, you best bet is this:
1. apt-get the build requirements, get the source 2../configure && make 3. sudo checkinstall make install 4. distribute the resulting.deb package across your network if needed
But this 1/10 of 1% wo care are most likely developers or so called opinion leaders. If they jump ship it is much much worse than the loss of 1 customer in 1000.
Not like it will buy them much time. It'll be harder to analyse and patch, or work around with virtualization technics, but done nonetheless. OSX/86 will run on cloned boxes.
But there is also a big loss of credibility: will I ever trust a kernel I and a large public doesn't have the source for, with no peer review at all? If you want to hide something devious (DRM, spyware, etc.), the kernel is the right place.
Given a closed kernel is ineffective in one way, and can be misused on the other hand, there might be other facets to this story then just protecting hardware sales.
That's the whole point: *test to the standard* then you don't have to test for *every browser*.
Maybe you have to tweak for the main browsers weaknesses afterwards, although safari, opera should work flawlessly already. So you would test for standards compliance, IE and FF, just 3 targets either with a more valuable result.
Wine is great, but it is also a moving target subject to Microsoft meddling. If Wine gets too good, Microsoft can "accidentally" break it at will. But Microsoft can't afford to do that with its own Windows API.
The author clearly has no clue how Wine is working. Wine exactly does what he claims Apple should do, implementing MS APIs. Now MS does break their own APIs sometimes. Never mind they can *extend* it any time, rely on the new parts in their own applications and development tools, and thus break any old foreign API implementation.
In short Apple would be in the same troubles as Wine, only a few years behind in work. They might be smarter, or not, so YMMV.
Some facts are wrong, or Linux specific where described as Unix-generic (for example, other Unixes have varying priority levels). Most of this is trivial to system administratiors, yet there is unneccessary detail for beginners. Too unfocused to be useful to any audience.
ratings: Helpful: no (x) Useful: [1] not at all (x)
This, like quite a lot of IBM devnet articles, seems to be produced for page count, not usefulnes.
As for not being a real Linux, that's nonsense, too. Linspire Five is a Debian-based Linux, and the company itself is a leading member of the DCC Alliance.
Actually the DCC is quite a mess, trying to get Debian or a subset thereof LSB-conformant, with LSB beeing an even greater mess. And Debian is not a member of DCC, and not at all happy about the use of their name in that regard.
With advertisments of this kind, no wonder there is a lot of disdain around. Practically with the opening sentence, he confirmed my prejudices.
You can get a PostgreSQL developer on your promises too. You can even train one of your own workers to be a PostgreSQL contributor/developer. As PostgreSQL is open, you don't need to rely on foreigners to get access to anything should you be inclined to invest the time and money to look yourself. You can get involved steering the future development. Or you can fork the project for total control. Now where are these Oracle options, aside from buying out the company?
That you can get deeper insight into Oracle's inner workings by their support than into any *open* source DB is self contradictionary. The process is different though, I admit that.
First screenshot, "Dave, welcome to the computer". Dr. Dave Bowman is greeted quite similiarly in this movie by the mission's HAL 9000 computer. Which subsequently goes to kill off the crew members. Oh joy, happy future ahead.
Of course you put in energy in form of solid fuel, and that's mostly gone after the fire is burnt.
I assume they carefully checked for other sources their extra energy could come from, found none yet, so called it "unknown source". They'll find it eventually. Nothing new to see here, please move on...
Transparent access to Microsoft source code would be very much in the security interest of their customers (and every other internet citizen) too, as MS would have incentive to fix broken stuff in the face of outraged customers.
But I very much doubt Microsoft would appreciate anyone posting MS source code. Seems like code development is very opaque there too.
And I doubt MS wants *all* of their EC papers made public either, and they'll for sure cry foul if the EC would publish the rest.
As much as I would like working Anti-DRM clauses, they might pose a serious problem with Debian. According to the social contract, a license is only acceptable to Debian, if (among others) it does not discriminate against groups of users or fields of usage. A clause forbidding use in DRM apps might therefore preclude GPL3 software in Debian?
By many Linux (the kernel) is seen as *the* prototypical OS project, yet it is missing here.
Oth, I didn't even recognize dyne:bolic without reading the description. And including Outfoxed, while they even admit it is not an OS project per se, shows they were just scrambling to find any 10 points to fill the list and space on their site. Clueless.
1. Your comments are very Oracle specific. You only show why stored procedures/triggers are bad with Oracle, not in principle. And I believe the right to disable triggers can be managed in Oracle too, just to name one flaw.
2. I also suggested using Postgres' extensible type mechanism to create a new field type that implements an encrypted field. This new type can be used as declarative as in Oracle. After the initial work (which can be outsourced) there is no procedural programming to be done.
CREATE TYPE MY3DES...
CREATE TABLE secretstuff (
INT id PRIMARY KEY,
MY3DESTYPE secret )
3. Nitpick: The ALTER TABLE command is not "declarative", it is a Data Definition/Alteration command and quite procedural. SQL is not purely declarative. INSERT, UPDATE are procedural too, in a different way. I agree SQL is quite high level, and obscures the actual low level algorithms used by automatically selecting optimal ones, but nonetheless there are procedural elements.
4. You probably only know MySQL, your last paragraph shows this. Forget treating PostgreSQL and MySQL as equal. Read up on Postgres. It is much closer to Oracle than to MySQL. I don't want to disparage MySQL here, these 2 open source DBs have very different audiences and that was my original point.
I won't reply after this, because I think we are repeating arguments and the whole point is moot -- if data needs to be encrypted "at rest", I'd do this at volume level (encrypted block devices) where the data is stored, completely independant of DB apps.
So the Oracle Password Wallet is completely magical and does not suffer from the drawbacks you wrote about above.
I never suggested embedding passwords into the code directly, but of course stored procedures can retrieve the passwords by whatever means neccessary (from a password wallet if neccessary).
I wonder how you can purely declarative instead of precedural crypto. Surely, somewhere some code has to actively do it. And I did not suggesst you code the crypto routines yourself, of course stored procedures would only be thin glue code to some (open, of your choice!) crypto library and password managing mechanism. After having those SPs, crypto would be solely declariative from the point of the table designer's view too.
Lastly, you seem to forget that Orcale's stored procedure performance applies to Postgres too, or you have not seen smart SP programmers yet. I recommend to use extended types so PG knows how to build indices and smart queries for your new (encrypted) column types. (Never mind you could hack the postgres source if brave enough, but that would be overkill and stupid imho).
First, where does Oracle store that magical key? Somewhere OBFUSCATED? We all know about security by obscurity right?
Than, PostgreSQL implements stored procedures and triggers which makes it easy to automate encrypting of columns too, or do any transformation on reading/writing from your records automatically. (Yes, function based indices and other goodies too.)
Quite likely someone already wrote something like this, and maybe it is even in your contrib/ directory. But it sure is more sensibly named than DBMS_OBFUSCATION_TOOLKIT.
Last, I bet Postgres supports more languages for programming embedded procedures in than either Oracle or DB2.
So your company is developing software for 35 years now. They must be doing it right.
Dont't ruin it just to save a couple of hours here and there, and to appease some bean counters with fancy reports about hours saved, and projects bungled in the process. Find out how they have worked in the past, and maybe try to improve slightly once you absolutely understand it, but do not just put down standards. It will only hurt.
Beware the difference between hard RT and soft RT applications/OSes.
RTLinux is a hardtime microkernel, running the whole Linux kernel as a low priority task. RTLinux' *own* tasks (or just interrupt handlers) are very limited, and have lots of restrictions communicating with the standard Linux kernel und userspace, which in itself does *not* run with realtime capabilities (I simplified a bit). The promises (latency) made by RTLinux are absolute, barring hardware faults, and are therefore suitable for high precision control applications, think nuclear, chemical production plant, mobile phone radio control, etc.
Audio/Video and Games are usually classified *soft realtime*. Nothing catastrophic happens at a missed deadline. Linux can be made to schedule certain tasks at (soft) realtime priority optimizing for low latency, instead of maximizing overall system throughput. There's nowhere the low latency or reliability of RTLinux, but it doesn't need to be, and A/V applications can use all the standard libraries and infrastructure of Linux (or Windows XP).
Not hellish hard, done already for lsb packages. Alien would need to convert rpm packages' dependencies too, like it does for lsb packages already. So converted rpm packages would play along with the central Debian package database.
Even if that works, it is still a bad idea. Packages are made and QA tested by a distributor for their own distribution. Dependencies are only really meaningful for one distribution. Different distributions have different policies, different infrastructure packages to depend on. In practice, you cannot even mix and match rpms from suse and RH safely, or even differnt major RH versions.
Mixing with Debian, with its rich set of high quality infrastructure packages, will not work for all but very simple, non crucial packages, or will result in reduced functionality or bugs. For example, how should RH font rpms know how to register their fonts with defoma, the Debian font manager? The fonts will be installed all right, but applications (like X, OOo, or ghostscript) would need to be configured by hand to use them. And I doubt anyone will provide enterprise grade support for such a hackish setup.
If they are going to rework RH rpms (and thereby fork them) to play along nicely, they could just rebuild them as debs and save all the hassle.
The promise to be able to pick from different distributions' package pools is snake oil of the finest, although it gets old by now. Also, Debian already has by far the largest package pool available, and most of the features promised to be developed are present already, so I am not impressed at all.
But Bittorrent *is* decentralized. Sooner or later new tracker hubs will spring up, in different countries, with more anonymous management, or perhaps closed or semi-closed user groups. Contrary to napsters central servers, you can use any tracker host you can find or setup yourself.
Not that I ever download movies. Heck, I mostly go to cinemas to socialize with friends, not for the great flicks.
Slashdot Mirror
Fancy you quote the MS Windows kernel as a shining example of having a wonderful reputation for stability and security.
Malicious allegations aside, just the ability to hide away sloppy work has created a nightmare.
You do not specify exactly which kernels from IBM, HP you have in mind, but if you speak of their unices, at least their ancestors were in the open, the academic, or at least licensed/known to a lot of people for a long time, and they have not exactly prospered and advanced a whole lot recently.
Flaimebait indeed.
Whoever tries 1) or 2) of this will learn one thing fast: when installing packages from out of your own distro or closely associated providers, regardless of package format, those package severely lack integration.
./configure && make .deb package across your network if needed
The ISO standard is doomed for the same reason LSB hasn't really taken off. Sure, a package might install, but to make it useable and interact with the rest of your system much more than this is neccessary. The slow (and usually thorough) pace of ISO will make any standard it produces in the field of fast paced distro development stale the day it comes out. Never mind the complexity of the task is on the order of managing several distros at once, blindfolded, while producing pretty Powerpoint presentations for the comittee.
If you really need something not available in Debian/Ubuntu, you best bet is this:
1. apt-get the build requirements, get the source
2.
3. sudo checkinstall make install
4. distribute the resulting
But this 1/10 of 1% wo care are most likely developers or so called opinion leaders. If they jump ship it is much much worse than the loss of 1 customer in 1000.
Not like it will buy them much time. It'll be harder to analyse and patch, or work around with virtualization technics, but done nonetheless. OSX/86 will run on cloned boxes.
But there is also a big loss of credibility: will I ever trust a kernel I and a large public doesn't have the source for, with no peer review at all? If you want to hide something devious (DRM, spyware, etc.), the kernel is the right place.
Given a closed kernel is ineffective in one way, and can be misused on the other hand, there might be other facets to this story then just protecting hardware sales.
That's the whole point: *test to the standard* then you don't have to test for *every browser*.
Maybe you have to tweak for the main browsers weaknesses afterwards, although safari, opera should work flawlessly already. So you would test for standards compliance, IE and FF, just 3 targets either with a more valuable result.
MS might have had a bigger installed base of SSL-capable webservers in the past, but that's not the same as secure. Whatever marketing says.
The author clearly has no clue how Wine is working. Wine exactly does what he claims Apple should do, implementing MS APIs. Now MS does break their own APIs sometimes. Never mind they can *extend* it any time, rely on the new parts in their own applications and development tools, and thus break any old foreign API implementation.
In short Apple would be in the same troubles as Wine, only a few years behind in work. They might be smarter, or not, so YMMV.
Some facts are wrong, or Linux specific where described as Unix-generic (for example, other Unixes have varying priority levels). Most of this is trivial to system administratiors, yet there is unneccessary detail for beginners. Too unfocused to be useful to any audience.
ratings:
Helpful: no (x)
Useful: [1] not at all (x)
This, like quite a lot of IBM devnet articles, seems to be produced for page count, not usefulnes.
Actually the DCC is quite a mess, trying to get Debian or a subset thereof LSB-conformant, with LSB beeing an even greater mess. And Debian is not a member of DCC, and not at all happy about the use of their name in that regard.
With advertisments of this kind, no wonder there is a lot of disdain around. Practically with the opening sentence, he confirmed my prejudices.
You can get a PostgreSQL developer on your promises too. You can even train one of your own workers to be a PostgreSQL contributor/developer. As PostgreSQL is open, you don't need to rely on foreigners to get access to anything should you be inclined to invest the time and money to look yourself. You can get involved steering the future development. Or you can fork the project for total control. Now where are these Oracle options, aside from buying out the company?
That you can get deeper insight into Oracle's inner workings by their support than into any *open* source DB is self contradictionary. The process is different though, I admit that.
I agree on your second paragraph.
First screenshot, "Dave, welcome to the computer". Dr. Dave Bowman is greeted quite similiarly in this movie by the mission's HAL 9000 computer. Which subsequently goes to kill off the crew members. Oh joy, happy future ahead.
Of course you put in energy in form of solid fuel, and that's mostly gone after the fire is burnt.
...
I assume they carefully checked for other sources their extra energy could come from, found none yet, so called it "unknown source". They'll find it eventually. Nothing new to see here, please move on
Transparent access to Microsoft source code would be very much in the security interest of their customers (and every other internet citizen) too, as MS would have incentive to fix broken stuff in the face of outraged customers.
But I very much doubt Microsoft would appreciate anyone posting MS source code. Seems like code development is very opaque there too.
And I doubt MS wants *all* of their EC papers made public either, and they'll for sure cry foul if the EC would publish the rest.
So, if I would d/l something I never had intention to spend cash on otherwise, there is no financial loss either, isn't it?
Hypothetically of course, with the crap coming out of hollywood not even downloading is worth the bother nowadays.
It is not "just because". Appearantly some people find the license annoying (scroll up slightly for a proof).
...
You yourself listed beeing not free (enough) as one of the reasons you do not claim nonsense
I personally don't mind there beeing 2 projects, if any one dies we still have the other one.
As much as I would like working Anti-DRM clauses, they might pose a serious problem with Debian. According to the social contract, a license is only acceptable to Debian, if (among others) it does not discriminate against groups of users or fields of usage. A clause forbidding use in DRM apps might therefore preclude GPL3 software in Debian?
IANAL & INADD (... Debian Developer)
By many Linux (the kernel) is seen as *the* prototypical OS project, yet it is missing here.
Oth, I didn't even recognize dyne:bolic without reading the description. And including Outfoxed, while they even admit it is not an OS project per se, shows they were just scrambling to find any 10 points to fill the list and space on their site. Clueless.
1. Your comments are very Oracle specific. You only show why stored procedures/triggers are bad with Oracle, not in principle. And I believe the right to disable triggers can be managed in Oracle too, just to name one flaw.
...
l -createtype.html
2. I also suggested using Postgres' extensible type mechanism to create a new field type that implements an encrypted field. This new type can be used as declarative as in Oracle. After the initial work (which can be outsourced) there is no procedural programming to be done.
CREATE TYPE MY3DES
CREATE TABLE secretstuff (
INT id PRIMARY KEY,
MY3DESTYPE secret )
PG Manual: http://www.postgresql.org/docs/8.1/interactive/sq
3. Nitpick: The ALTER TABLE command is not "declarative", it is a Data Definition/Alteration command and quite procedural. SQL is not purely declarative. INSERT, UPDATE are procedural too, in a different way. I agree SQL is quite high level, and obscures the actual low level algorithms used by automatically selecting optimal ones, but nonetheless there are procedural elements.
4. You probably only know MySQL, your last paragraph shows this. Forget treating PostgreSQL and MySQL as equal. Read up on Postgres. It is much closer to Oracle than to MySQL. I don't want to disparage MySQL here, these 2 open source DBs have very different audiences and that was my original point.
http://www.postgresql.org/
I won't reply after this, because I think we are repeating arguments and the whole point is moot -- if data needs to be encrypted "at rest", I'd do this at volume level (encrypted block devices) where the data is stored, completely independant of DB apps.
So the Oracle Password Wallet is completely magical and does not suffer from the drawbacks you wrote about above.
I never suggested embedding passwords into the code directly, but of course stored procedures can retrieve the passwords by whatever means neccessary (from a password wallet if neccessary).
I wonder how you can purely declarative instead of precedural crypto. Surely, somewhere some code has to actively do it. And I did not suggesst you code the crypto routines yourself, of course stored procedures would only be thin glue code to some (open, of your choice!) crypto library and password managing mechanism. After having those SPs, crypto would be solely declariative from the point of the table designer's view too.
Lastly, you seem to forget that Orcale's stored procedure performance applies to Postgres too, or you have not seen smart SP programmers yet. I recommend to use extended types so PG knows how to build indices and smart queries for your new (encrypted) column types. (Never mind you could hack the postgres source if brave enough, but that would be overkill and stupid imho).
Jürgen
First, where does Oracle store that magical key? Somewhere OBFUSCATED? We all know about security by obscurity right?
Than, PostgreSQL implements stored procedures and triggers which makes it easy to automate encrypting of columns too, or do any transformation on reading/writing from your records automatically. (Yes, function based indices and other goodies too.)
Quite likely someone already wrote something like this, and maybe it is even in your contrib/ directory. But it sure is more sensibly named than DBMS_OBFUSCATION_TOOLKIT.
Last, I bet Postgres supports more languages for programming embedded procedures in than either Oracle or DB2.
So your company is developing software for 35 years now. They must be doing it right.
Dont't ruin it just to save a couple of hours here and there, and to appease some bean counters with fancy reports about hours saved, and projects bungled in the process. Find out how they have worked in the past, and maybe try to improve slightly once you absolutely understand it, but do not just put down standards. It will only hurt.
Don't change a working system.
Beware the difference between hard RT and soft RT applications/OSes.
RTLinux is a hardtime microkernel, running the whole Linux kernel as a low priority task. RTLinux' *own* tasks (or just interrupt handlers) are very limited, and have lots of restrictions communicating with the standard Linux kernel und userspace, which in itself does *not* run with realtime capabilities (I simplified a bit). The promises (latency) made by RTLinux are absolute, barring hardware faults, and are therefore suitable for high precision control applications, think nuclear, chemical production plant, mobile phone radio control, etc.
Audio/Video and Games are usually classified *soft realtime*. Nothing catastrophic happens at a missed deadline. Linux can be made to schedule certain tasks at (soft) realtime priority optimizing for low latency, instead of maximizing overall system throughput. There's nowhere the low latency or reliability of RTLinux, but it doesn't need to be, and A/V applications can use all the standard libraries and infrastructure of Linux (or Windows XP).
Not hellish hard, done already for lsb packages. Alien would need to convert rpm packages' dependencies too, like it does for lsb packages already. So converted rpm packages would play along with the central Debian package database.
Even if that works, it is still a bad idea. Packages are made and QA tested by a distributor for their own distribution. Dependencies are only really meaningful for one distribution. Different distributions have different policies, different infrastructure packages to depend on. In practice, you cannot even mix and match rpms from suse and RH safely, or even differnt major RH versions.
Mixing with Debian, with its rich set of high quality infrastructure packages, will not work for all but very simple, non crucial packages, or will result in reduced functionality or bugs.
For example, how should RH font rpms know how to register their fonts with defoma, the Debian font manager? The fonts will be installed all right, but applications (like X, OOo, or ghostscript) would need to be configured by hand to use them. And I doubt anyone will provide enterprise grade support for such a hackish setup.
If they are going to rework RH rpms (and thereby fork them) to play along nicely, they could just rebuild them as debs and save all the hassle.
The promise to be able to pick from different distributions' package pools is snake oil of the finest, although it gets old by now. Also, Debian already has by far the largest package pool available, and most of the features promised to be developed are present already, so I am not impressed at all.
Jürgen
But Bittorrent *is* decentralized. Sooner or later new tracker hubs will spring up, in different countries, with more anonymous management, or perhaps closed or semi-closed user groups. Contrary to napsters central servers, you can use any tracker host you can find or setup yourself.
Not that I ever download movies. Heck, I mostly go to cinemas to socialize with friends, not for the great flicks.
J.
If authors distribute with the "GPL2 or any later version" boilerplate clause, *any* GPL3, however bizarr, will be compatible with GPL2.
Some don't, the Linux kernel beeing one as far as I remember.
Jürgen