I read this as SUN forbidding Debian to package their JVM in a Debian package.
do not distribute additional software intended to replace any component(s) of the Software
This would mean Debian wouldn't be allowed to ship with gcj, Jikes RVM, JRockit, Kaffe or whatever. To me it sounds quite unreasonable for SUN to want to be able to veto what can go into Debian.
defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software
So SUN wants Debian to pay their legal fees? Silly Debian for not wanting to do that.
To me these terms sound quite unreasonable, I know I wouldn't want to adhere to them if I could decide what went into Debian.
Patents don't protect an end product -- just a particular process that yields that end product
This doesn't seem to hold for at least some of the software patents out there. Amazon managed to patent "one click shopping". This means nobody else can implement one click shopping, even if they use an entirely different process (source code) from what Amazon does.
If what you say was true (which I wish it was), software patents wouldn't give you any protection you don't already have using copyrights, but for a fee.
Regarding the JRVM, it has no interpreter AFAIK, it only has a JIT. As I've never done anything with the JRVM except read about it, it might still suck in a lot of ways, but it is a compiler so at least a naive interpreter won't be the source of its potential suckiness.
Regarding your performance worries, you are wrong.
An interpreted language doesn't have to be run by an interpreter. It can be run by a just-in-time compiler as well. A just-in-time compiler (JIT) does exactly what any other compiler would. The only difference is that it is lazy and compiles only the stuff needed to run the program, and it does so on demand.
After stuff has been compiled, you have the same code (assembly for your intel/amd/ppc/... chip) whether you compiled it using a JIT or a static compiler.
If your compiler is lousy, performance will suck regardless of whether your compiler is a JIT or a static compiler.
Write it in an interpreted language. Have the interpreter run itself. I'm dead serious.
The benefits would be that porting the OS and all programs running on it to a new platform would consist of porting the virtual machine only.
Also, all code would be bounds-checked and stack-overflow protected, so a lot of today's security holes wouldn't be possible to create. With garbage collection, memory leaks would be a minor problem as well.
To get a lot for free, you could base it on IBM's JRVM, a virtual machine for Java, written in Java.
The drawback of not allowing C code to run natively is that there's a lot of software out there that'll be hard to support. This may be solvable, but I haven't given any thought to it so I don't know.
This blocking list is somewhat experimental and should not be used in a production environment where legitimate email must be delivered. It is growing more stable and is used by many large sites now. However, SpamCop is aggressive and often errs on the side of blocking mail - users should be warned and given information about how their mail is filtered. Ideally they should have a choice of filtering options. Many mailservers can operate with blacklists in a "tag only" mode, which is preferable in many situations.
If people use Spamcop's blacklist in some other way than the one recommended by Spamcop, how is that Spamcop's fault?
The installer can be written using the full GNOME / KDE / OpenGL / whatever-rings-your-bell libraries.
You know your hardware is supported before installing.
Also, imagine reading everything from the network instead of from a CD. Then you could make a Windows program based on loadlin or whatever. Put a link to it on a web-page that says "Wanna try Linux? Click here!".
After it has booted into Linux and started GNOME / KDE / XFCE / Whatever, the desktop contains a "Click here to install Linux on your hard drive".
Ask him for the name of a software vendor that provides "liability". Find an EULA from said software vendor. Have your boss read it (and weep hopefully).
It costs a fare amount for a large organisation like that to move from one application to another let alone a whole OS
Hint: They will be replacing both their apps and their OS anyway. Thus they will have those costs anyway, independently if they switch to an MS solution or a Linux based one.
Or why would switching to new versions of Windows and MS Office be free from "retraining stuff + installation cost etc"?
This is IMO the way to go for installers. Instead of the current specialized install program that has to run in a special environment without X, network or anything else, I'd love to have a live CD like this.
The CD should get me into a fully working desktop environment. If I give the word, it should install itself on the hard drive. This way, the installer could be written using all of GNOME, KDE, OpenGL or whatever rings your bell. Now that Live CDs are obviously doable, I don't really see why any distro would want to ship a classic install program anymore.
Also, for newcomers, they get to see proof that Linux actually works before diving into it. And if it doesn't work on their system, I bet they'd rather find out sooner rather than later.
And, to push the envelope even further, why not a Windows exe that re-boots the computer into a Live-CD like environment, but with everything read from an FTP server rather than a CD? Wanna try Linux? Go to this URL and press "OK". Like it so much you want to have it on your hard drive? Just click "Install on Hard Drive" on your KDE / GNOME desktop. It could even be possible (I don't know) to keep running on the existing Internet connection without breaking it through the reboot, thus voiding the need for the user to re-connect after reboot.
Imagine there is a buffer overflow in the kernel's brk() implementation that nobody knows about. What kind of security measures (other than finding the bug and fixing it) could prevent that buffer overflow from being exploited by an attacker?
When that question has been answered, go implement the answer, and this won't happen again.
go for Linux, even though it was cheaper (and hence their margins lower)
Why would their margins be lower because Linux is cheaper for the customer? The margin is the difference between what the customer pays and what it costs them to provide it. If Linux is cheaper for them, their margins can very well be higher for Linux, even though it is cheaper for the customer.
This way, everybody benefits (except for Microsoft).
Despite the abscence of funding, Debian is the second most popular Linux distribution we find on internet web sites, surpassed only by Red Hat, and leaving the likes of SuSE and Mandrake in its wake.
So if Netcraft are to be believed, Richard Seibt seems to be right in that it is a two distro world; its just that SuSE isn't one of them.
But I was disappointed with the nautilus cd burner. It is a really great feature, but somehow, it is not at all visible. But I was disappointed with the nautilus cd burner. It is a really great feature, but somehow, it is not at all visible.
Someone said that what MacOS X does is to automatically open the CD-burning software when a writable CDROM is inserted. Sounds like a great idea to me.
Lots of people keep complaining about dselect being bad, but very few of them actually comes up with anything specific. How this "dselect bad" comment could be rated as "Insightful" is beyond me.
What exactly is wrong with dselect? What do you use instead? Why do you find that tool superior?
Slashdot Mirror
I read this as SUN forbidding Debian to package their JVM in a Debian package.
do not distribute additional software intended to replace any component(s) of the Software
This would mean Debian wouldn't be allowed to ship with gcj, Jikes RVM, JRockit, Kaffe or whatever. To me it sounds quite unreasonable for SUN to want to be able to veto what can go into Debian.
defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software
So SUN wants Debian to pay their legal fees? Silly Debian for not wanting to do that.
To me these terms sound quite unreasonable, I know I wouldn't want to adhere to them if I could decide what went into Debian.
This doesn't seem to hold for at least some of the software patents out there. Amazon managed to patent "one click shopping". This means nobody else can implement one click shopping, even if they use an entirely different process (source code) from what Amazon does.
If what you say was true (which I wish it was), software patents wouldn't give you any protection you don't already have using copyrights, but for a fee.
Regarding the JRVM, it has no interpreter AFAIK, it only has a JIT. As I've never done anything with the JRVM except read about it, it might still suck in a lot of ways, but it is a compiler so at least a naive interpreter won't be the source of its potential suckiness.
An interpreted language doesn't have to be run by an interpreter. It can be run by a just-in-time compiler as well. A just-in-time compiler (JIT) does exactly what any other compiler would. The only difference is that it is lazy and compiles only the stuff needed to run the program, and it does so on demand.
After stuff has been compiled, you have the same code (assembly for your intel/amd/ppc/... chip) whether you compiled it using a JIT or a static compiler.
If your compiler is lousy, performance will suck regardless of whether your compiler is a JIT or a static compiler.
The benefits would be that porting the OS and all programs running on it to a new platform would consist of porting the virtual machine only.
Also, all code would be bounds-checked and stack-overflow protected, so a lot of today's security holes wouldn't be possible to create. With garbage collection, memory leaks would be a minor problem as well.
To get a lot for free, you could base it on IBM's JRVM, a virtual machine for Java, written in Java.
The drawback of not allowing C code to run natively is that there's a lot of software out there that'll be hard to support. This may be solvable, but I haven't given any thought to it so I don't know.
The LUG's web page is in English. Why not in the language spoken by most Iraqis?
What I don't understand is, why is it so obvious that it was Mike who should hand over his domain to MS and not the other way around?
I realize this will probably be modded Funny, but I really want to know. Anybody?
This way you wouldn't need to mess with extra backup hardware, and your data would be safe(ish) from this kind of attack.
You forgot to list Word documents. They can contain macro viruses.
Blocking them might get people to stop passing Word documents around for no reason.
They should have something that can be associated with NetBSD's wide platform support. Like a chameleon or a cockroach or something.
Thanks, but that was kind of obvious. It was the other parts that needed explaining.
This blocking list is somewhat experimental and should not be used in a production environment where legitimate email must be delivered. It is growing more stable and is used by many large sites now. However, SpamCop is aggressive and often errs on the side of blocking mail - users should be warned and given information about how their mail is filtered. Ideally they should have a choice of filtering options. Many mailservers can operate with blacklists in a "tag only" mode, which is preferable in many situations.
If people use Spamcop's blacklist in some other way than the one recommended by Spamcop, how is that Spamcop's fault?This would have all sorts of benefits:
- The installer can be written using the full GNOME / KDE / OpenGL / whatever-rings-your-bell libraries.
- You know your hardware is supported before installing.
Also, imagine reading everything from the network instead of from a CD. Then you could make a Windows program based on loadlin or whatever. Put a link to it on a web-page that says "Wanna try Linux? Click here!".After it has booted into Linux and started GNOME / KDE / XFCE / Whatever, the desktop contains a "Click here to install Linux on your hard drive".
A nice way to lower the barrier of entry, no?
Ask him for the name of a software vendor that provides "liability". Find an EULA from said software vendor. Have your boss read it (and weep hopefully).
Hint: They will be replacing both their apps and their OS anyway. Thus they will have those costs anyway, independently if they switch to an MS solution or a Linux based one.
Or why would switching to new versions of Windows and MS Office be free from "retraining stuff + installation cost etc"?
The CD should get me into a fully working desktop environment. If I give the word, it should install itself on the hard drive. This way, the installer could be written using all of GNOME, KDE, OpenGL or whatever rings your bell. Now that Live CDs are obviously doable, I don't really see why any distro would want to ship a classic install program anymore.
Also, for newcomers, they get to see proof that Linux actually works before diving into it. And if it doesn't work on their system, I bet they'd rather find out sooner rather than later.
And, to push the envelope even further, why not a Windows exe that re-boots the computer into a Live-CD like environment, but with everything read from an FTP server rather than a CD? Wanna try Linux? Go to this URL and press "OK". Like it so much you want to have it on your hard drive? Just click "Install on Hard Drive" on your KDE / GNOME desktop. It could even be possible (I don't know) to keep running on the existing Internet connection without breaking it through the reboot, thus voiding the need for the user to re-connect after reboot.
Imagine there is a buffer overflow in the kernel's brk() implementation that nobody knows about. What kind of security measures (other than finding the bug and fixing it) could prevent that buffer overflow from being exploited by an attacker?
When that question has been answered, go implement the answer, and this won't happen again.
The reason Debian's installer is lagging is because once you get Debian installed you never have to do it again; apt-get makes upgrading too smooth.
If you're interested, help test it!
Why would their margins be lower because Linux is cheaper for the customer? The margin is the difference between what the customer pays and what it costs them to provide it. If Linux is cheaper for them, their margins can very well be higher for Linux, even though it is cheaper for the customer.
This way, everybody benefits (except for Microsoft).
What makes you think they are trying to "help linux become more mainstream"?
Despite the abscence of funding, Debian is the second most popular Linux distribution we find on internet web sites, surpassed only by Red Hat, and leaving the likes of SuSE and Mandrake in its wake.
So if Netcraft are to be believed, Richard Seibt seems to be right in that it is a two distro world; its just that SuSE isn't one of them.
Someone said that what MacOS X does is to automatically open the CD-burning software when a writable CDROM is inserted. Sounds like a great idea to me.
SUN probably wouldn't call that "without any costs what so ever".
This was a year or so ago though, so for all I know Aptitude may very well have improved since.
What exactly is wrong with dselect? What do you use instead? Why do you find that tool superior?