A local-to-local symlink is one that I open from my own machine that points to another file on my own machine. As the post mentions, local-to-local symlinks are on by default. No problem there.
A remote-to-local is a symlink on a network share that points to a file on my own machine. Local-to-remote is a link on my machine pointing to a network share, and remote-to-remote is a symlink on a network share pointing to another network share. All of these have security implications.
For local-to-remote, a critical system file could be replaced to point to a spoofed copy on a network share. For remote-to-local, I could wind up copying or deleting files from my own hard drive without realizing it. For remote-to-remote, I could think I'm accessing a safe server, but I'm really being redirected to an unsafe server without realizing it.
Of course, if all of these features are turned on via group policy, you have full, classic symlink support (target always resolved by the client, and Win2k and XP clients can't resolve them).
The issue is not usually with user apps taking up gigs and gigs of virtual address space: it's that everything on the system is at the mercy of the kernel's single address space. 64-bit opens up kernel-mode code such as device drivers to use a lot more virtual address space.
Before I get flamed -- note that I said *virtual* address space. This does not mean that all the virtual addresses necessarily map to physical memory or that all the memory is always paged-in. But, everything running in the system context -- ie, kernel mode -- shares one address space and it can be a limiting factor.
These aren't organizations "stuck" on using Windows. They didn't fear change. They believed that running Linux would cost less than Windows enough to do it. Maybe, they even did it for some of the very reasons you mentioned such as bugs and security issues.
What they found is that at the end of the day, their costs didn't go down using Linux instead of Windows..... they went up!
You can't accuse these guys of giving in to the Microsoft hype, because they turned their backs on the Microsoft hype, gave in to the Linux hype, and got burned.
Essentially, Windows is *too* secure and now breaks tons of programs -- so don't install it!
2 -- "XP SP2 IS TOTALLY INSECURE!!"
Too many Windows services are on, which means lots of apps -- including harmful ones -- are still able to run, which means XP SP2 is totally insecure -- so don't install it!
You can't have life both ways. Yes, added security will break *some* apps, but most will still work. Yes, it's not as secure as, say, a OpenBSD installation where you turn on one service at a time -- but end-users aren't expected to go through turning on service by service and tweak firewall settings every time they install a new app!!
By the way, for corporate deployments, most of that stuff (services, firewall, etc) can be administrated through Group Policy, anyway, so the default settings apply much more to home users than corporate ones who can pick and choose what services, firewall settings, etc to allow on their Windows PCs.
Who needs to store stuff on a dinky 35 GB Jaz drive when you can use a seperate hard drive or cheap storage server with inexpensive 300 GB drives readily available! When you factor in software RAID, it's just ridiculous to imaging flipping in and out 35 GB disks. Iomega should just give up in the storage arena.
All the energy in the world won't keep your body from being splattered all over the back wall without inertial dampeners! No word on when that tech will be available yet...:)
It's really easy to jump on the Anti-Microsoft bandwagon when it's time, and say "Linux is ready for the desktop, it's high-quality and easy to use, why doesn't it overtake that crap from Redmond". But, when push comes to shove and sombody points out the things that scare off non-technical users from using Linux, OSS "advocates" really seem to have a hard time accepting constructive criticism.
Look -- if it's just a hobby OS, fine, this criticism is totally baseless and cruel. But, if you all want to see your labor of love have a real shot at the desktop market, you're going to have to take criticism like that and work with it -- if it seems angry, it's because end-users get frustrated when they're promised an easy-to-use system, and they have to spend more time wrestling with configuration than actually doing what they need the OS to do.
Either take the criticism as advice and use it to add value to your software so it can be accessible to a larger audience, or accept that your OSS project is just a hobby.
There could be some filter driver causing some havoc in the file IO stack. Does your IT group install any software (antivirus, CD burning, etc) that adds any filter drivers? Check out the %windir%\system32\drivers directory. If there are new.sys files that were added around the time the trouble started that may be your culprit.
If you have physical access to a machine, security is compromised anyway. You can rip out the hard drive and take/modify the bits by force if you want. If the machine is locked in a box, then you can't reboot it without being root, so the exploit doesn't work and you're still safe.
Walter: "Oh, please dear!? I've got news for you: the Supreme Court has roundly rejected prior restraint!"
Dude: "Walter, this is not a first amendment thing!"
Walter: "Lady, I got buddies who died face-down in the muck..."
Can any motivated and talented enough 16-year-old car theif break into your car and steal it? Probably, the answer is yes. Sufficiently motivated people can find ways around security. What do you do if you own a car that you don't want stolen? Buy an alarm system and have it installed. Similarly, you buy a firewall and antivirus and install that on Windows.
All the comments so far have been arguing that "no set release date means more QA". From my experience with open source software, this is complete crap. In many cases, commercially used open source software is developed by organizations such as Red Hat and IBM who, we hope, have significant QA teams and resources.
But, for the projects contributed by individuals, with a single or small group of developers -- who wants to do testing? Everybody wants to be a developer, and the more new features, the more bang, the more people will be drawn to the program, so more often than not new features and frequent releases rather than testing are the focus. Most of the time, you can guess from the sheer frequency of builds with new features that QA is not being taken into account. This system works great for projects that enthusiasts use -- individuals request new features, play with the product, and in return, report bugs. This does not work for companies of any size who expect software to work properly right out of the box, where the "feedback loop" of reporting bugs is a last resort.
Open source programmers and commercial programmers alike are under pressure to release early and release often. And in both the open source world and the commercial world, there are groups that excel at QA and groups that don't take QA seriously enough.
There are several definitions here along the lines of knowledge discovery. Data mining is actually a burgeoning field -- governments and corporations have tons of data and no idea what to do with it. Some applications include targeted advertising (such as direct mailing and click-stream analysis) and credit card freud detection (ever get a call after a large or out-of-state purchase?). I have heard the IRS uses it to detect tax freud and other criminal behavior. Oh yea, and in case you ever wondered why Wal Mart is in business textbooks and K-Mart filed for bankruptcy... supposedly, Wal Mart even uses it to decide product placement within each store!
Data Mining is NOT the process of recovering or otherwise retrieving data. Data Mining is the process of discovering knowledge through data that has already been obtained (usually through statistical and/or AI techniques). I.e., data retrieval/collection is a prerequisite for Data Mining.
Anybody here ever used SE Linux? It wasn't nearly mature enough for serious testing, let alone deployment. I would say it was an academic exercise in extending the Flask architecture to Linux, and leave it at that. The code is still available, and anybody interested can work on making the system useable. It would take a concerted effort among kernel hackers and/or security gurus in the open source community to get the code at any realistic state anyway -- so if you really want it, fire up sourceforge and make it happen!
Yep. Who would have guessed 20 years ago that personal computers would turn out to be big beige boxes under a desks with wires running all over the place and a monitor today!
Wait a minute.... IBM PC... I had one of those 20 years ago!
Slashdot Mirror
This post covers it all: http://www.osnews.com/permalink.php?news_id=16524& comment_id=183548
A local-to-local symlink is one that I open from my own machine that points to another file on my own machine. As the post mentions, local-to-local symlinks are on by default. No problem there.
A remote-to-local is a symlink on a network share that points to a file on my own machine. Local-to-remote is a link on my machine pointing to a network share, and remote-to-remote is a symlink on a network share pointing to another network share. All of these have security implications.
For local-to-remote, a critical system file could be replaced to point to a spoofed copy on a network share. For remote-to-local, I could wind up copying or deleting files from my own hard drive without realizing it. For remote-to-remote, I could think I'm accessing a safe server, but I'm really being redirected to an unsafe server without realizing it.
Of course, if all of these features are turned on via group policy, you have full, classic symlink support (target always resolved by the client, and Win2k and XP clients can't resolve them).
The issue is not usually with user apps taking up gigs and gigs of virtual address space: it's that everything on the system is at the mercy of the kernel's single address space. 64-bit opens up kernel-mode code such as device drivers to use a lot more virtual address space.
Before I get flamed -- note that I said *virtual* address space. This does not mean that all the virtual addresses necessarily map to physical memory or that all the memory is always paged-in. But, everything running in the system context -- ie, kernel mode -- shares one address space and it can be a limiting factor.
What a big shocker... the "father" of Java says that the .NET runtime and the C# language are terrible and you should use Java instead..
What did you expect him to say "Great job guys, everyone better use that instead of Java! I suck!"
These aren't organizations "stuck" on using Windows. They didn't fear change. They believed that running Linux would cost less than Windows enough to do it. Maybe, they even did it for some of the very reasons you mentioned such as bugs and security issues.
What they found is that at the end of the day, their costs didn't go down using Linux instead of Windows..... they went up!
You can't accuse these guys of giving in to the Microsoft hype, because they turned their backs on the Microsoft hype, gave in to the Linux hype, and got burned.
There are two sets of articles on XP SP2:
1 -- "XP SP2 BREAKS TONS OF APPS!!"
Essentially, Windows is *too* secure and now breaks tons of programs -- so don't install it!
2 -- "XP SP2 IS TOTALLY INSECURE!!"
Too many Windows services are on, which means lots of apps -- including harmful ones -- are still able to run, which means XP SP2 is totally insecure -- so don't install it!
You can't have life both ways. Yes, added security will break *some* apps, but most will still work. Yes, it's not as secure as, say, a OpenBSD installation where you turn on one service at a time -- but end-users aren't expected to go through turning on service by service and tweak firewall settings every time they install a new app!!
By the way, for corporate deployments, most of that stuff (services, firewall, etc) can be administrated through Group Policy, anyway, so the default settings apply much more to home users than corporate ones who can pick and choose what services, firewall settings, etc to allow on their Windows PCs.
Just out of curiosity, does anybody know how ReiserFS "plugins" differ from Windows file system filter drivers?
Who needs to store stuff on a dinky 35 GB Jaz drive when you can use a seperate hard drive or cheap storage server with inexpensive 300 GB drives readily available! When you factor in software RAID, it's just ridiculous to imaging flipping in and out 35 GB disks. Iomega should just give up in the storage arena.
All the energy in the world won't keep your body from being splattered all over the back wall without inertial dampeners! No word on when that tech will be available yet... :)
It's really easy to jump on the Anti-Microsoft bandwagon when it's time, and say "Linux is ready for the desktop, it's high-quality and easy to use, why doesn't it overtake that crap from Redmond". But, when push comes to shove and sombody points out the things that scare off non-technical users from using Linux, OSS "advocates" really seem to have a hard time accepting constructive criticism.
Look -- if it's just a hobby OS, fine, this criticism is totally baseless and cruel. But, if you all want to see your labor of love have a real shot at the desktop market, you're going to have to take criticism like that and work with it -- if it seems angry, it's because end-users get frustrated when they're promised an easy-to-use system, and they have to spend more time wrestling with configuration than actually doing what they need the OS to do.
Either take the criticism as advice and use it to add value to your software so it can be accessible to a larger audience, or accept that your OSS project is just a hobby.
Martin Freeman was Ricky C from Ali G Indahouse! Resssspect!
There could be some filter driver causing some havoc in the file IO stack. Does your IT group install any software (antivirus, CD burning, etc) that adds any filter drivers? Check out the %windir%\system32\drivers directory. If there are new .sys files that were added around the time the trouble started that may be your culprit.
If you have physical access to a machine, security is compromised anyway. You can rip out the hard drive and take/modify the bits by force if you want. If the machine is locked in a box, then you can't reboot it without being root, so the exploit doesn't work and you're still safe.
Walter: "Oh, please dear!? I've got news for you: the Supreme Court has roundly rejected prior restraint!"
Dude: "Walter, this is not a first amendment thing!"
Walter: "Lady, I got buddies who died face-down in the muck..."
Can any motivated and talented enough 16-year-old car theif break into your car and steal it? Probably, the answer is yes. Sufficiently motivated people can find ways around security. What do you do if you own a car that you don't want stolen? Buy an alarm system and have it installed. Similarly, you buy a firewall and antivirus and install that on Windows.
New YM!! Like, oh my gawd no way, is it the one with Justin Timberlake!?!? I'd better run to the mawl...
Did anybody else read "Desert Robot Race" to mean that there is a community of robots living in the desert?
Buy Sun [servers, NOT Sun stock, whatever you do!!! -ed]!
Tell them you'll switch to Windows if they can sell you the server licences cheaper than RedHat. :)
All the comments so far have been arguing that "no set release date means more QA". From my experience with open source software, this is complete crap. In many cases, commercially used open source software is developed by organizations such as Red Hat and IBM who, we hope, have significant QA teams and resources.
But, for the projects contributed by individuals, with a single or small group of developers -- who wants to do testing? Everybody wants to be a developer, and the more new features, the more bang, the more people will be drawn to the program, so more often than not new features and frequent releases rather than testing are the focus. Most of the time, you can guess from the sheer frequency of builds with new features that QA is not being taken into account. This system works great for projects that enthusiasts use -- individuals request new features, play with the product, and in return, report bugs. This does not work for companies of any size who expect software to work properly right out of the box, where the "feedback loop" of reporting bugs is a last resort.
Open source programmers and commercial programmers alike are under pressure to release early and release often. And in both the open source world and the commercial world, there are groups that excel at QA and groups that don't take QA seriously enough.
There are several definitions here along the lines of knowledge discovery. Data mining is actually a burgeoning field -- governments and corporations have tons of data and no idea what to do with it. Some applications include targeted advertising (such as direct mailing and click-stream analysis) and credit card freud detection (ever get a call after a large or out-of-state purchase?). I have heard the IRS uses it to detect tax freud and other criminal behavior. Oh yea, and in case you ever wondered why Wal Mart is in business textbooks and K-Mart filed for bankruptcy... supposedly, Wal Mart even uses it to decide product placement within each store!
Data Mining is NOT the process of recovering or otherwise retrieving data. Data Mining is the process of discovering knowledge through data that has already been obtained (usually through statistical and/or AI techniques). I.e., data retrieval/collection is a prerequisite for Data Mining.
Anybody here ever used SE Linux? It wasn't nearly mature enough for serious testing, let alone deployment. I would say it was an academic exercise in extending the Flask architecture to Linux, and leave it at that. The code is still available, and anybody interested can work on making the system useable. It would take a concerted effort among kernel hackers and/or security gurus in the open source community to get the code at any realistic state anyway -- so if you really want it, fire up sourceforge and make it happen!
Yep. Who would have guessed 20 years ago that personal computers would turn out to be big beige boxes under a desks with wires running all over the place and a monitor today!
Wait a minute.... IBM PC... I had one of those 20 years ago!
It's refreshing to see that somebody has finally written an insightful article on the Linux/M$ battle that wasn't complete flamebait. Geez!