That's what I was afraid of. If you want to learn more about how secure Java is, I highly recommend trying to write a shell for launching Java programs. You'd need to become intimately familiar with classloaders and the rest of the java.lang package. Then you could write as many programs to attempt to crash the VM as you like. Good luck on that.
All the same, it is in the nature of security considerations that they are designed for today's challenges, but must inevitably meet those of tomorrow. There is no silver bullet.
There will always be security problems. For example, there is no solution to social engineering. However, we *can* solve the problems that cause nearly all of the remote exploits today. Java was built from the ground up with near-perfect security.
Most new programmers to Java assume that there must be a way out of the JVM, because there are always ways to break systems. Any programmer worth his salt soon learns that this just isn't the case. The Java Platform is as inpenetrable as modern technology can make it.
I presume you keep framing this in terms of J2EE because that's part of your vision of the future?
No, I frame in J2EE because it's the perfect example of where things *could* be broken. J2EE is a very large system with more components than many OSes. There are thousands of these servers deployed in the wild, yet remote exploits just don't exist against them. Any exploits have to target the specific holes in the company's codebase. (e.g. Some people are dumb enough to write servlets that allow access to arbitrary files.) Even these holes can be closed off if a Security Manager is used.
Java is used in Cell Phones, Web Browsers, High End Servers, and just about anything else that an attacker might want to penetrate. Yet day in and day out these systems withstand all attempts to be exploited by would be attackers. If that doesn't say something to you, then it should.
If you don't mind my asking, how much experience do you have with Java Platform/Language? These concerns are silly. You can't crash a J2EE server with a remote exploit, and you can't crash a Java OS with a remote exploit. The language was designed from the ground up to prevent exactly those sorts of things. Once you write a program loader in Java using a classloader, it becomes apparent how impossible it is for a program to break out of its sandbox.:-)
No, you pointed out alternatives. That's not what this is about. If Linux were popular enough, there would be a Photoshop, Adobe, InDesign, and possibly even Microsoft Office. But first Linux needs to make sure that users can actually install this software.:-)
First off, we expect that packages that are pairwise compatible, will be compatible in every combination.
If only it were that simple. Let's say that we have Mozilla, Java, and a package that can "glue" Java to other programs. Independently, Mozilla and Java work fine. Together they work fine. Each works fine with the glue package. But if something is screwed up in the glue package, Mozilla, Java, and the glue may no longer function when together. Even more distirbing is Mozilla plugins that step on each other and screw up packages that were working fine before.
Guidelines can help. That's the only reason why things work in the first place. But they don't guarantee, I'm afraid.
Linux won't get better from more stupid people using it. It will get better from more smart users, and those are very well capable of editing their config files.
That's simply insane. People got out of the business of doing all but the most basic car maintenence YEARS ago. People got out of the business of managing all but the most basic computer tasks YEARS ago. Now you want to send them back to the "Edit your Autoexec.bat/System.ini/Win.ini/Config.sys" hell? WHY?
It has nothing to do with people being stupid. It has everything to do with people having better things to focus on. If I'm a musician, I just want to install a program that lets me read and create sheet music. If you can make that one-click, GREAT! I really don't need to know, want to know, or should be expected to know how to do complex system management!
The traditional answer to any request is "okay, go and implement it yourself". Most people are incapable of doing that. The others will cater to their own needs. Such is life.
If that is the answer, then Linux will never achieve the Desktop market penetration that the community CLAIMS it wants. There can't be two ways about this. Either we're going to support end users or we're not. It doesn't matter if it's a new distro specifically designed for end users. We just have to support them.
Right now I think you're confused on so many accounts that I'd have to decline
There's no confusion here, only opinions. While they may differ, I see no reason to insult each other over them.
There is commercial software for Linux, maybe not a specific app from a specific company but then more than likely an equivilent one cn be found. Database? Check. Wordprocessing, check. Spreadsheet, check..
Dude, I already addressed that argument. This isn't about whether alternatives exist, it's about what consumers want and need.
... and setting security on the file system so that INETSRV_ANONYMOUS (or whatever the IIS account is) only had access to places it's meant to fixes the problem, without the need for a security manager. If you were talking about anything other than filesystem protection, you might possibly have a case - but in this case you don't.
Except for one minor difference that you failed to note. In the Java Server I'm suggesting, the security settings are built into the shipped copy. There's NO CONFIGURATION to do! With IIS, you have to explicitly set the system permissions. That's always a good idea, but how many admins fail to take this basic precaution?
However when your "server" has a bug, it's not just your computer. It's your TV, your Stereo, your PS4, and your computer.
That's a bug? You obviously haven't seen some of the setups these days. I just built a computer that is my CD Player, DVD Player, Television, Radio, and Computer all in one! And I've been considering purchasing a large LCD TV to replace my 17" LCD screen that I've been using. I hardly think that's a bug.:-)
BTW, the PS4 is still separate (for its graphics hardware and such), it just feeds off the server for networking and video streams.
In addition this sounds like a jack of all trades and a master of none, trying to get all that functionality into one device will make it convoluted and hard to use.
Have you SEEN the home entertainment systems that people have setup? You can't tell me that this would be more complicated. If anything, it should simplify things quite a bit.
Oh oh, and you want to clog up the little free wireless spectrum we have left.
How is that different than the little wireless spectrum we're already clogging? Many users already have wireless in their homes. This would simply replace it with a new hub. There's nothing stopping someone from turning off the Wireless and running cable instead, but that is such a PITA.
Maybe one day those flaws will be addressed, but you had stated "near future" in your post.
Read it again. I said that development of Unix would take it through the near future. I said the long-term future belongs to something else.:-)
To me that means within 10 years MAX
Pfff. We'll have the first offering of this sort of home entertainment in 5 years.
If you're running IIS as the internet account instead of as local system, then you can get the same effect just by correctly administrating your system
No, you wouldn't. The grandparent stated that there was a flaw in IIS where the URL was decoded a second time and used without security checking. That broke IIS's security. Java's Security Manager sits outside the program's security and checks on EVERY file access in the system. In an OS setting, the server could come pre-packaged with Security Manager rules saying that files outside directory WEBAPPS cannot be accessed. If such a bug exists in this mythical application, IT WOULD BE IMPOSSIBLE TO EXPLOIT!
Java's security model doesn't help you at all here.
Can't assume an attack's going to be over the network. Could just as easy be a trojan. They do tend to be single threaded. All of which is a bit beside the point.
But what would the trojan do? Would it simply run a program just to crash it? That seems kind of pointless. The point isn't that threads don't die. It's that it's impossible for an attacker to use this in any meaningful way.
However, until someone tries to crack it in earnest and out in the wild then we can't be sure that nothing has been overlooked.
It HAS been tested in earnest. Applets are an example of an area where the Java security model is in effect. There was exactly ONE semi-successful virus (see: Strange Brew), and it was only able to spread on systems where the Security Manager was not in effect. i.e. Your standard desktop applications. There is one other issue that I'm aware of, but it was a flaw in the JVM->Native mapping (specifically the JavaScript support). On a fully code-managed system, this is impossible.
Trust me, crackers would LOVE to use Java for malware. Unfortunately (for them), no one has yet managed to break the Security Manager.
The question is whether the language is the proper place to add such protection.
Whoa! Hold up there! The protection is not in the language. It's in the platform. The Java Language is independent from its platform, and provides very little in the way of security features. However, the Platform is as secure as it gets, no matter *what* language you use in it. Python, Ruby, BeanShell, JavaScript and many other languages have been made to work on the Java Platform.
Remember, your OS/CPU combination are one type of platform. Java is higher level platform that solves many of the issues with previous platforms.
Granted, you need an OS that does its job properly, but then a buggy java runtime would have the same problems as a buggy OS.
It's far easier to prove the correct execution of Java Bytecode than it is to prove the security of today's OSes. In fact, even the most secure OSes (e.g. OpenBSD) have been shown to have root exploits. You can't do that in Java. You just can't. There's no ledge on which you can grab a purchase. The best you can hope for is something like the TENEX flaw which allowed programs to hook into the paging notifier to check if something was paged from disk. By aligning the password characters with the end of the page and swapping the next page out to disk, an attacker was able to know that a password character was correct based on if a page fault happened.
Of course, security has moved on quite a bit from there, so I seriously doubt such flaws would be present.
I think there's a lot to recommend the idea of letting the OS handle security
If Java is the OS, it WOULD be handling security.
One of the BSDs, OpenBSD I think, demonstrates how well this can work. Currently it has zero outstanding security advisories and a policy of full disclosure.
You can't get much better than that.
Yes, yes you can. You can have an OS *never* have a root exploit, or even a critical exploit. Java can do that. Think, with all the J2EE servers running out there, and all the webbrowsers with Java installed, how many have experienced major flaws in the Java architecture or VM? The answer is a resounding ONE. (The one I described above.) Even programming flaws in J2EE systems fail to lead to system security issues like gaining root access. Usually, it's a matter of allowing web clients access to data they shouldn't have. (That's a whole other problem unrelated to system design.)
And C's parameter passing mechanism is secure so long as the programmer always checks buffer lengths.
And Java's is secure even if the programmer DOESN'T check buffer lengths. "ArrayOut
People will do what their OS Provider recommends them to do. Installers are the recommended procedure on Windows. Apple provides developers with the Installer software. Debian provides DEBs, Red Hat provides RPMs, Gentoo provides emerge, and GoboLinux provides InstallPackage. If these distros pre-installed the Autopackage software, then users and developers would start considering it "standard" and use it. Until then, it will be an uphill battle.
Which isn't to say that I won't promote Autopackage. I think it's the greatest thing since sliced bread. It's certainly better than the installers I rolled from shell scripts. (Although, arguably, it has the advantage of waiting until GNOME and KDE stablized. I didn't have that advantage when I rolled my scripts. Do you know what a PITA it is trying to make install software that works on RedHat 7, 8, and 9? Blech.)
I purchase a new home computer package from Best Buy and bring it home. When I open the box, I find a box that's similar to an integrated stereo/receiver, CD Player, and DVD Player, but with an integrated network switch and Wireless hub support. I plug my LCD TV into this box, all my speakers, and my internet cable.
I now have a home entertainment center where I can watch television, listen to the radio, download MP3s, watch TV Shows and Movies off the 'net, and other cool stuff. I just have to pull the remote out of the box to get started.
But wait! What's this next to the remote? Why, it's what looks like a super-slim laptop! I open it up, and it automatically connects to my "home server" device using the wireless hub that I noted earlier. The desktop is projected to this laptop via a wireless Browser session. From this gizmo, I'm able to surf the net, edit text file and spreadsheets, and do pretty much most of the Desktop Office work I could do with a full computer. The only difference is that all the files are actually stored on the "home server" device.
So then I go out and I purchase a game console. There seems to be no place to put a Disc, but there is a network port. So I hook it up to my "home server" and turn it on. There I'm presented with a shopping list of games I can purchase! Super-cool!
So I select a game and wait for the server to load the first level. When it does, I start blasting away monsters. I get tired of single player, so I kick it into multi-player play. It immediately starts playing games over the internet. No console configuration required!
So then I get a TV in another room. I buy a little "Wireless TV" box to plug it into. This Wireless TV box connects back to the "home server" in my living room over wireless! Soon I'm watching TV, playing music, and other entertainment stuff in another room!
Once a secure, managed code OS is used on this "home server", there's no reason why you can't automatically share your Desktop on the internet, so you can always access you stuff at neighbor's, coffee shops, hotels, and work! Your "home server" could even run its own mail server and website!
A distro packaing itself with autopakages would be foolish - the autopackage developers themselves will tell you this.
That wasn't what I was referring to. I was referring to having the autopackage software pre-installed, and encouraging users to use this technique. Without distro support, Autopackage will always remain a fringe product.
Thanks for proving that Debian (where P is around 15.000) cannot possibly exist.
Thanks for putting words in my mouth. I didn't prove that Debian can't exist, I proved that it's nearly impossible to prevent packaging errors. With 15,000 packages, the number of possible configurations is 2.817E4515. That's a STAGGERING number for so few packages!
Making a system work with that many packages is actually straightforward: define stable interfaces. Debian has quite a number of them, collectively called "Debian Policy".
Debian Policy only defines how an application should be packaged. It does not fix any potential errors that may occur. For example, if a dependency package is missing (say, because it's considered old and was removed) how does the user resolve that dependency?
Wrong. All you have to is adhere to the FHS and install into/usr/local and/var/local.
What's wrong is assuming that/usr/local is the right place to put software. According to the FHS, Mozilla and FireFox should go in/opt. Can you name a distro that does this? And because no distros do this, many systems cannot launch FireFox and Mozilla simultaneously. Oops.
Better yet, you can a.deb yourself. What else do you want?
Something that an average user can actually *DO*. My wife would have my head on a platter for dinner if I told her to create her own DEB file for software! Good God, man! What are you thinking with?
What I want (and what Linux needs) are software distribution methods that are open, easy to use, fully support commercial software, and don't require a degree in computer science. Something like this, maybe?
Quick, remind me... Linux NEEDS commercial software to do what exactly?
Obtain general market acceptance on the Desktop! Was that fast enough?
Are you really sure that NEEDS to be done?
If the Linux community wants that acceptance, then yes. I keep hearing an affirmative on that, but then people say really dumb things like "users can just edit their system config files."
Better do more coding and less talking.
No worries. I have the code in the pipeline. All this talking is working well for recruitment. Want to join?
Put CD in drive, run installer, hit next a few times, watch a progress bar.
Try to run the program, and it breaks because SDL isn't properly installed. (I've tried running Unreal on Linux. It wasn't pretty.)
And if I'm downloading a demo, I have to remember the step of setting the execute bit. Users don't understand this, and DO have problems. That's one of the reasons why packages were invented.
One that can read and understand about 5 Very simple sentences. It's a one line addition to a text file fer cripes sake.
Ok, here we go:
1. Open a terminal window.
2. Type "sudo vi/etc/sources"
3. Move the cursor to the end, and hit 'o'.
4. Type 'http://myrepository.com/repository'
5. Hit 'ESC', type ':wq', then 'exit'.
User's reponse: "What's a terminal?"
People have to stop thinking that users can do this crap. They have NO IDEA how to use a command line, nor do they want to know. The command line is a POWER USER FEATURE. The sooner this percolates through people's heads, the better.
Because setting up a repository is incredibly easy, and it makes his software MUCH easier for end users to install / update.
Windows:
1. Click on Download.
2. Run Installer.
Linux:
1. Do the five steps above.
2. Run the package manager.
3. Find the correct package among the myriad of options.
4. Install.
This is easier, how?
One that would like ALL his software automatically updated when he does and apt-get update; apt-get upgrade.
1. You don't always want that. Control is a good thing.
2. There are much better solutions to system-wide updates than screwing the user on software installation.
Because his repository and the distro repository are ISOLATED.
Which is EXACTLY THE PROBLEM. The dependencies can change, breaking your repository. It happens all the time with third party repositories, yet everyone keeps suggesting that third party is the way to go.
Or, if it isn't handled at all, the application crashes.
No, actually. If it isn't handled at all, the current thread dies. If you're using a single threaded program, then your program is dead. However, networked programs are almost never single threaded. That's why C/C++ servers used to come down all the time on errors whereas modern J2EE server handle the error as best as possible and move on. The biggest problem with servers today is accidental memory leaks.
I understand that. Look, suppose a black hat finds an exploit that lets him tweak the parameters of the Java runtime.
Never should happen. That's what the Java Security System is for. Even without that in place, each program should be running in a semi-separated environment. I actually have such a system on my laptop which allows telnet logins and servers to all run under the same JVM with no impact between programs. The System class has been subtly modified to prevent programs from changing the system wide parameters. If your program writes to System.out for example, I guarantee you that the message will get to the right place.
Now if the entire OS is a java runtime, then these protections no longer apply. The runtime has access to superuser privileges, and changes made the runtime affect all users.
You're asssuming a single user environment when you shouldn't be. If you extend Java down to the OS level, you have to add standard multi-user protection. The key is that it's much easier to add this protection in Java than any other language. For example, starting a program in its own classloader would prevent it from interfacing with any other code other than system classes.
That's great, to the extent that it works as it's supposed to work. It's not, after all as if all those buffer overflows in C were coded in because the coder thought they were cool.
No, they weren't designed that way on purpose. However, C/C++ have no built-in security model. There's no way to check for that other than attempting to build your own security framework on top, and/or relying on the OS to do its job. Both options are far from perfect. Java has no such problems.
A Java security manager can check every file passing through the system. A Java security manager can check every network connection. A Java security manager cannot be uninstalled by an attacker unless you give him permission to do so. Java's Security model is inescapable as long as it's used and not ignored.
Nope. You're going to walk over to your game console gizmo and use that. The server will automatically pipe the video output to the LCD television you're using. The console will pull its software from the internet (No media!) via the server, and use the server as a gateway for internet gaming.
1. What end user can add a repository without special training?
2. Why would a commercial vendor want to setup an entire repository just to distribute his 5 megs of software?
3. What end user is going to want to add a repository for every piece of software he wants to install?
4. How does the vendor know that primary repository changes won't break his software without even a new OS release coming out?
I'm afraid that the market has looked at this option and soundly rejected it. It just isn't a workable solution.
Uhh, wrong again. Again, I'm no genius but I figured out make, make install when there was no binary I couldn't get from different apt-sources.
1. You would have to be an unparalleled genius to find the source for binary-only software.
2. It can take hours to days to install an application from source. What end user wants to wait that long?
3. Differences in build environments can often cause failures. What end user wants to trouble-shoot compile-time issues?
4. Dependencies are not auto-managed in a build system. What end user wants to track down the 30+ dependencies for a single program. (And I'm not exagerating the number 30.)
This solution has been analyzed up and down by the market and soundly rejected.
I addressed this very issue here. Interesting, the most common response I got is Read The F*** Manual and "It works for me, you're an idiot." Sometimes I wonder if people actually care about making Linux accessable, or are just paying lip service.:-/
Yes. If they allow each other to. There are a lot of areas where Open Source fails to deliver, particularly in the areas of comprehensive solutions. Using an on-topic example, PhotoShop still has several killer features that GIMP doesn't. InDesign provides a far easier to use typesetting environment than Tex. Many users still wish they could have MS Office on Linux despite the amount of functionality in OpenOffice and KOffice. Game Creators expect to be compensated for the blood, sweat, tears, and massive overtime they put into their games.
The truth is that the two MUST co-exist if we want to get anywhere. The problem today is that they are not allowed to co-exist. Most distros today use a packaging system that pulls from a central repository. While this has many advantages for the usability of OSS, it sucks for commercial software. There's no *good* way of delivering commercial software to a Linux system. (I know, I've tried.)
These OSes are closed systems where no new software can be introduced without the blessing of the distro maintainers. That's not only not good, it goes against the very ideals of an open computer! A computer is a device that allows you to provide instructions on how to complete a task. While the door is open for "approved" OSS software and personal C++ development, where's the door for commercial software?
I've heard a lot of arguments that packaging systems can be fixed to allow for commercial repositories. Unfortunately, no one has actually explained how this would work. And as I've pointed out, the math says it's can't work. Having 2^P (where P is the number of packages available) as the possible number of software combinations (any of which can interfere with each other) is not a good situation to be in!
Linux (the community) NEEDS commercial software. But if it wants to attract it, it needs to be in a position to spark another Shareware revolution like the one seen after Windows 95. Make it easy for users to use their system. Make it so they can visit VersionTracker or Tucows and try everything under the sun! Give the users back control of their computers! Viva la Software!
Slashdot Mirror
Not a whole lot.
That's what I was afraid of. If you want to learn more about how secure Java is, I highly recommend trying to write a shell for launching Java programs. You'd need to become intimately familiar with classloaders and the rest of the java.lang package. Then you could write as many programs to attempt to crash the VM as you like. Good luck on that.
All the same, it is in the nature of security considerations that they are designed for today's challenges, but must inevitably meet those of tomorrow. There is no silver bullet.
There will always be security problems. For example, there is no solution to social engineering. However, we *can* solve the problems that cause nearly all of the remote exploits today. Java was built from the ground up with near-perfect security.
Most new programmers to Java assume that there must be a way out of the JVM, because there are always ways to break systems. Any programmer worth his salt soon learns that this just isn't the case. The Java Platform is as inpenetrable as modern technology can make it.
I presume you keep framing this in terms of J2EE because that's part of your vision of the future?
No, I frame in J2EE because it's the perfect example of where things *could* be broken. J2EE is a very large system with more components than many OSes. There are thousands of these servers deployed in the wild, yet remote exploits just don't exist against them. Any exploits have to target the specific holes in the company's codebase. (e.g. Some people are dumb enough to write servlets that allow access to arbitrary files.) Even these holes can be closed off if a Security Manager is used.
Java is used in Cell Phones, Web Browsers, High End Servers, and just about anything else that an attacker might want to penetrate. Yet day in and day out these systems withstand all attempts to be exploited by would be attackers. If that doesn't say something to you, then it should.
If you don't mind my asking, how much experience do you have with Java Platform/Language? These concerns are silly. You can't crash a J2EE server with a remote exploit, and you can't crash a Java OS with a remote exploit. The language was designed from the ground up to prevent exactly those sorts of things. Once you write a program loader in Java using a classloader, it becomes apparent how impossible it is for a program to break out of its sandbox. :-)
No, you pointed out alternatives. That's not what this is about. If Linux were popular enough, there would be a Photoshop, Adobe, InDesign, and possibly even Microsoft Office. But first Linux needs to make sure that users can actually install this software. :-)
First off, we expect that packages that are pairwise compatible, will be compatible in every combination.
If only it were that simple. Let's say that we have Mozilla, Java, and a package that can "glue" Java to other programs. Independently, Mozilla and Java work fine. Together they work fine. Each works fine with the glue package. But if something is screwed up in the glue package, Mozilla, Java, and the glue may no longer function when together. Even more distirbing is Mozilla plugins that step on each other and screw up packages that were working fine before.
Guidelines can help. That's the only reason why things work in the first place. But they don't guarantee, I'm afraid.
Linux won't get better from more stupid people using it. It will get better from more smart users, and those are very well capable of editing their config files.
That's simply insane. People got out of the business of doing all but the most basic car maintenence YEARS ago. People got out of the business of managing all but the most basic computer tasks YEARS ago. Now you want to send them back to the "Edit your Autoexec.bat/System.ini/Win.ini/Config.sys" hell? WHY?
It has nothing to do with people being stupid. It has everything to do with people having better things to focus on. If I'm a musician, I just want to install a program that lets me read and create sheet music. If you can make that one-click, GREAT! I really don't need to know, want to know, or should be expected to know how to do complex system management!
The traditional answer to any request is "okay, go and implement it yourself". Most people are incapable of doing that. The others will cater to their own needs. Such is life.
If that is the answer, then Linux will never achieve the Desktop market penetration that the community CLAIMS it wants. There can't be two ways about this. Either we're going to support end users or we're not. It doesn't matter if it's a new distro specifically designed for end users. We just have to support them.
Right now I think you're confused on so many accounts that I'd have to decline
There's no confusion here, only opinions. While they may differ, I see no reason to insult each other over them.
Look, here's my ideas laid out in four parts, and here's a two part followup that provides more details. If you want to join, send me an email. If you don't, then don't. No skin off my nose.
There is commercial software for Linux, maybe not a specific app from a specific company but then more than likely an equivilent one cn be found. Database? Check. Wordprocessing, check. Spreadsheet, check..
Dude, I already addressed that argument. This isn't about whether alternatives exist, it's about what consumers want and need.
... and setting security on the file system so that INETSRV_ANONYMOUS (or whatever the IIS account is) only had access to places it's meant to fixes the problem, without the need for a security manager. If you were talking about anything other than filesystem protection, you might possibly have a case - but in this case you don't.
Except for one minor difference that you failed to note. In the Java Server I'm suggesting, the security settings are built into the shipped copy. There's NO CONFIGURATION to do! With IIS, you have to explicitly set the system permissions. That's always a good idea, but how many admins fail to take this basic precaution?
However when your "server" has a bug, it's not just your computer. It's your TV, your Stereo, your PS4, and your computer.
:-)
:-)
That's a bug? You obviously haven't seen some of the setups these days. I just built a computer that is my CD Player, DVD Player, Television, Radio, and Computer all in one! And I've been considering purchasing a large LCD TV to replace my 17" LCD screen that I've been using. I hardly think that's a bug.
BTW, the PS4 is still separate (for its graphics hardware and such), it just feeds off the server for networking and video streams.
In addition this sounds like a jack of all trades and a master of none, trying to get all that functionality into one device will make it convoluted and hard to use.
Have you SEEN the home entertainment systems that people have setup? You can't tell me that this would be more complicated. If anything, it should simplify things quite a bit.
Oh oh, and you want to clog up the little free wireless spectrum we have left.
How is that different than the little wireless spectrum we're already clogging? Many users already have wireless in their homes. This would simply replace it with a new hub. There's nothing stopping someone from turning off the Wireless and running cable instead, but that is such a PITA.
Maybe one day those flaws will be addressed, but you had stated "near future" in your post.
Read it again. I said that development of Unix would take it through the near future. I said the long-term future belongs to something else.
To me that means within 10 years MAX
Pfff. We'll have the first offering of this sort of home entertainment in 5 years.
If you're running IIS as the internet account instead of as local system, then you can get the same effect just by correctly administrating your system
:-)
No, you wouldn't. The grandparent stated that there was a flaw in IIS where the URL was decoded a second time and used without security checking. That broke IIS's security. Java's Security Manager sits outside the program's security and checks on EVERY file access in the system. In an OS setting, the server could come pre-packaged with Security Manager rules saying that files outside directory WEBAPPS cannot be accessed. If such a bug exists in this mythical application, IT WOULD BE IMPOSSIBLE TO EXPLOIT!
Java's security model doesn't help you at all here.
Yes, it does. It helps a LOT.
Can't assume an attack's going to be over the network. Could just as easy be a trojan. They do tend to be single threaded. All of which is a bit beside the point.
But what would the trojan do? Would it simply run a program just to crash it? That seems kind of pointless. The point isn't that threads don't die. It's that it's impossible for an attacker to use this in any meaningful way.
However, until someone tries to crack it in earnest and out in the wild then we can't be sure that nothing has been overlooked.
It HAS been tested in earnest. Applets are an example of an area where the Java security model is in effect. There was exactly ONE semi-successful virus (see: Strange Brew), and it was only able to spread on systems where the Security Manager was not in effect. i.e. Your standard desktop applications. There is one other issue that I'm aware of, but it was a flaw in the JVM->Native mapping (specifically the JavaScript support). On a fully code-managed system, this is impossible.
Trust me, crackers would LOVE to use Java for malware. Unfortunately (for them), no one has yet managed to break the Security Manager.
The question is whether the language is the proper place to add such protection.
Whoa! Hold up there! The protection is not in the language. It's in the platform. The Java Language is independent from its platform, and provides very little in the way of security features. However, the Platform is as secure as it gets, no matter *what* language you use in it. Python, Ruby, BeanShell, JavaScript and many other languages have been made to work on the Java Platform.
Remember, your OS/CPU combination are one type of platform. Java is higher level platform that solves many of the issues with previous platforms.
Granted, you need an OS that does its job properly, but then a buggy java runtime would have the same problems as a buggy OS.
It's far easier to prove the correct execution of Java Bytecode than it is to prove the security of today's OSes. In fact, even the most secure OSes (e.g. OpenBSD) have been shown to have root exploits. You can't do that in Java. You just can't. There's no ledge on which you can grab a purchase. The best you can hope for is something like the TENEX flaw which allowed programs to hook into the paging notifier to check if something was paged from disk. By aligning the password characters with the end of the page and swapping the next page out to disk, an attacker was able to know that a password character was correct based on if a page fault happened.
Of course, security has moved on quite a bit from there, so I seriously doubt such flaws would be present.
I think there's a lot to recommend the idea of letting the OS handle security
If Java is the OS, it WOULD be handling security.
One of the BSDs, OpenBSD I think, demonstrates how well this can work. Currently it has zero outstanding security advisories and a policy of full disclosure.
You can't get much better than that.
Yes, yes you can. You can have an OS *never* have a root exploit, or even a critical exploit. Java can do that. Think, with all the J2EE servers running out there, and all the webbrowsers with Java installed, how many have experienced major flaws in the Java architecture or VM? The answer is a resounding ONE. (The one I described above.) Even programming flaws in J2EE systems fail to lead to system security issues like gaining root access. Usually, it's a matter of allowing web clients access to data they shouldn't have. (That's a whole other problem unrelated to system design.)
And C's parameter passing mechanism is secure so long as the programmer always checks buffer lengths.
And Java's is secure even if the programmer DOESN'T check buffer lengths. "ArrayOut
People will do what their OS Provider recommends them to do. Installers are the recommended procedure on Windows. Apple provides developers with the Installer software. Debian provides DEBs, Red Hat provides RPMs, Gentoo provides emerge, and GoboLinux provides InstallPackage. If these distros pre-installed the Autopackage software, then users and developers would start considering it "standard" and use it. Until then, it will be an uphill battle.
Which isn't to say that I won't promote Autopackage. I think it's the greatest thing since sliced bread. It's certainly better than the installers I rolled from shell scripts. (Although, arguably, it has the advantage of waiting until GNOME and KDE stablized. I didn't have that advantage when I rolled my scripts. Do you know what a PITA it is trying to make install software that works on RedHat 7, 8, and 9? Blech.)
Think of it this way:
:-)
I purchase a new home computer package from Best Buy and bring it home. When I open the box, I find a box that's similar to an integrated stereo/receiver, CD Player, and DVD Player, but with an integrated network switch and Wireless hub support. I plug my LCD TV into this box, all my speakers, and my internet cable.
I now have a home entertainment center where I can watch television, listen to the radio, download MP3s, watch TV Shows and Movies off the 'net, and other cool stuff. I just have to pull the remote out of the box to get started.
But wait! What's this next to the remote? Why, it's what looks like a super-slim laptop! I open it up, and it automatically connects to my "home server" device using the wireless hub that I noted earlier. The desktop is projected to this laptop via a wireless Browser session. From this gizmo, I'm able to surf the net, edit text file and spreadsheets, and do pretty much most of the Desktop Office work I could do with a full computer. The only difference is that all the files are actually stored on the "home server" device.
So then I go out and I purchase a game console. There seems to be no place to put a Disc, but there is a network port. So I hook it up to my "home server" and turn it on. There I'm presented with a shopping list of games I can purchase! Super-cool!
So I select a game and wait for the server to load the first level. When it does, I start blasting away monsters. I get tired of single player, so I kick it into multi-player play. It immediately starts playing games over the internet. No console configuration required!
So then I get a TV in another room. I buy a little "Wireless TV" box to plug it into. This Wireless TV box connects back to the "home server" in my living room over wireless! Soon I'm watching TV, playing music, and other entertainment stuff in another room!
Once a secure, managed code OS is used on this "home server", there's no reason why you can't automatically share your Desktop on the internet, so you can always access you stuff at neighbor's, coffee shops, hotels, and work! Your "home server" could even run its own mail server and website!
Does that clarify the idea?
A distro packaing itself with autopakages would be foolish - the autopackage developers themselves will tell you this.
That wasn't what I was referring to. I was referring to having the autopackage software pre-installed, and encouraging users to use this technique. Without distro support, Autopackage will always remain a fringe product.
Thanks for proving that Debian (where P is around 15.000) cannot possibly exist.
/usr/local and /var/local.
/usr/local is the right place to put software. According to the FHS, Mozilla and FireFox should go in /opt. Can you name a distro that does this? And because no distros do this, many systems cannot launch FireFox and Mozilla simultaneously. Oops.
.deb yourself. What else do you want?
Thanks for putting words in my mouth. I didn't prove that Debian can't exist, I proved that it's nearly impossible to prevent packaging errors. With 15,000 packages, the number of possible configurations is 2.817E4515. That's a STAGGERING number for so few packages!
Making a system work with that many packages is actually straightforward: define stable interfaces. Debian has quite a number of them, collectively called "Debian Policy".
Debian Policy only defines how an application should be packaged. It does not fix any potential errors that may occur. For example, if a dependency package is missing (say, because it's considered old and was removed) how does the user resolve that dependency?
Wrong. All you have to is adhere to the FHS and install into
What's wrong is assuming that
Better yet, you can a
Something that an average user can actually *DO*. My wife would have my head on a platter for dinner if I told her to create her own DEB file for software! Good God, man! What are you thinking with?
What I want (and what Linux needs) are software distribution methods that are open, easy to use, fully support commercial software, and don't require a degree in computer science. Something like this, maybe?
Quick, remind me... Linux NEEDS commercial software to do what exactly?
Obtain general market acceptance on the Desktop! Was that fast enough?
Are you really sure that NEEDS to be done?
If the Linux community wants that acceptance, then yes. I keep hearing an affirmative on that, but then people say really dumb things like "users can just edit their system config files."
Better do more coding and less talking.
No worries. I have the code in the pipeline. All this talking is working well for recruitment. Want to join?
I agree. Autopackage is an awesome advancement in Linux. Unfortunately, not even one distro has embraced it! :-(
This page gives a good overview of Typesetting. :-)
as simple as the kids over at Microsoft who decided to implement an anti-piracy measure utilizing javascript without any input validation.
;-)
You mean I don't even have to hold down the Shift key?
Installing commercial software on Linux:
Put CD in drive, run installer, hit next a few times, watch a progress bar.
Try to run the program, and it breaks because SDL isn't properly installed. (I've tried running Unreal on Linux. It wasn't pretty.)
And if I'm downloading a demo, I have to remember the step of setting the execute bit. Users don't understand this, and DO have problems. That's one of the reasons why packages were invented.
One that can read and understand about 5 Very simple sentences. It's a one line addition to a text file fer cripes sake.
/etc/sources"
Ok, here we go:
1. Open a terminal window.
2. Type "sudo vi
3. Move the cursor to the end, and hit 'o'.
4. Type 'http://myrepository.com/repository'
5. Hit 'ESC', type ':wq', then 'exit'.
User's reponse: "What's a terminal?"
People have to stop thinking that users can do this crap. They have NO IDEA how to use a command line, nor do they want to know. The command line is a POWER USER FEATURE. The sooner this percolates through people's heads, the better.
Because setting up a repository is incredibly easy, and it makes his software MUCH easier for end users to install / update.
Windows:
1. Click on Download.
2. Run Installer.
Linux:
1. Do the five steps above.
2. Run the package manager.
3. Find the correct package among the myriad of options.
4. Install.
This is easier, how?
One that would like ALL his software automatically updated when he does and apt-get update; apt-get upgrade.
1. You don't always want that. Control is a good thing.
2. There are much better solutions to system-wide updates than screwing the user on software installation.
Because his repository and the distro repository are ISOLATED.
Which is EXACTLY THE PROBLEM. The dependencies can change, breaking your repository. It happens all the time with third party repositories, yet everyone keeps suggesting that third party is the way to go.
Or, if it isn't handled at all, the application crashes.
No, actually. If it isn't handled at all, the current thread dies. If you're using a single threaded program, then your program is dead. However, networked programs are almost never single threaded. That's why C/C++ servers used to come down all the time on errors whereas modern J2EE server handle the error as best as possible and move on. The biggest problem with servers today is accidental memory leaks.
I understand that. Look, suppose a black hat finds an exploit that lets him tweak the parameters of the Java runtime.
Never should happen. That's what the Java Security System is for. Even without that in place, each program should be running in a semi-separated environment. I actually have such a system on my laptop which allows telnet logins and servers to all run under the same JVM with no impact between programs. The System class has been subtly modified to prevent programs from changing the system wide parameters. If your program writes to System.out for example, I guarantee you that the message will get to the right place.
Now if the entire OS is a java runtime, then these protections no longer apply. The runtime has access to superuser privileges, and changes made the runtime affect all users.
You're asssuming a single user environment when you shouldn't be. If you extend Java down to the OS level, you have to add standard multi-user protection. The key is that it's much easier to add this protection in Java than any other language. For example, starting a program in its own classloader would prevent it from interfacing with any other code other than system classes.
That's great, to the extent that it works as it's supposed to work. It's not, after all as if all those buffer overflows in C were coded in because the coder thought they were cool.
No, they weren't designed that way on purpose. However, C/C++ have no built-in security model. There's no way to check for that other than attempting to build your own security framework on top, and/or relying on the OS to do its job. Both options are far from perfect. Java has no such problems.
A Java security manager can check every file passing through the system. A Java security manager can check every network connection. A Java security manager cannot be uninstalled by an attacker unless you give him permission to do so. Java's Security model is inescapable as long as it's used and not ignored.
Nope. You're going to walk over to your game console gizmo and use that. The server will automatically pipe the video output to the LCD television you're using. The console will pull its software from the internet (No media!) via the server, and use the server as a gateway for internet gaming.
:-)
Use the right peripheral for the right job.
*grin* Read my blog. I think you'll be pleasently surprised. :-)
Reality Check:
In apt, I add another source to etc/sources.list.
1. What end user can add a repository without special training?
2. Why would a commercial vendor want to setup an entire repository just to distribute his 5 megs of software?
3. What end user is going to want to add a repository for every piece of software he wants to install?
4. How does the vendor know that primary repository changes won't break his software without even a new OS release coming out?
I'm afraid that the market has looked at this option and soundly rejected it. It just isn't a workable solution.
Uhh, wrong again. Again, I'm no genius but I figured out make, make install when there was no binary I couldn't get from different apt-sources.
1. You would have to be an unparalleled genius to find the source for binary-only software.
2. It can take hours to days to install an application from source. What end user wants to wait that long?
3. Differences in build environments can often cause failures. What end user wants to trouble-shoot compile-time issues?
4. Dependencies are not auto-managed in a build system. What end user wants to track down the 30+ dependencies for a single program. (And I'm not exagerating the number 30.)
This solution has been analyzed up and down by the market and soundly rejected.
I addressed this very issue here. Interesting, the most common response I got is Read The F*** Manual and "It works for me, you're an idiot." Sometimes I wonder if people actually care about making Linux accessable, or are just paying lip service. :-/
Can Open Source and Commercial Software Coexist?
Yes. If they allow each other to. There are a lot of areas where Open Source fails to deliver, particularly in the areas of comprehensive solutions. Using an on-topic example, PhotoShop still has several killer features that GIMP doesn't. InDesign provides a far easier to use typesetting environment than Tex. Many users still wish they could have MS Office on Linux despite the amount of functionality in OpenOffice and KOffice. Game Creators expect to be compensated for the blood, sweat, tears, and massive overtime they put into their games.
The truth is that the two MUST co-exist if we want to get anywhere. The problem today is that they are not allowed to co-exist. Most distros today use a packaging system that pulls from a central repository. While this has many advantages for the usability of OSS, it sucks for commercial software. There's no *good* way of delivering commercial software to a Linux system. (I know, I've tried.)
These OSes are closed systems where no new software can be introduced without the blessing of the distro maintainers. That's not only not good, it goes against the very ideals of an open computer! A computer is a device that allows you to provide instructions on how to complete a task. While the door is open for "approved" OSS software and personal C++ development, where's the door for commercial software?
I've heard a lot of arguments that packaging systems can be fixed to allow for commercial repositories. Unfortunately, no one has actually explained how this would work. And as I've pointed out, the math says it's can't work. Having 2^P (where P is the number of packages available) as the possible number of software combinations (any of which can interfere with each other) is not a good situation to be in!
Linux (the community) NEEDS commercial software. But if it wants to attract it, it needs to be in a position to spark another Shareware revolution like the one seen after Windows 95. Make it easy for users to use their system. Make it so they can visit VersionTracker or Tucows and try everything under the sun! Give the users back control of their computers! Viva la Software!
Gah! Stupid SlashCode. The model should look like this:
HTML/CSS/JavaScript (Client) <-> Java (Server)