You can delete the kernel, system libraries or any other vital file on Linux too and it won't stop you. You need root you say? You need admin on Windows to delete them.
Non-admin accounts on Windows can't delete start up files unless someone has screwed with the default permissions. Any sane corporate environment is not giving admin rights to the general users.
System utilities like AV programs need full access to do their jobs so of course they have rights to do stupid things. Same thing could happen on Linux if a package manager or other system utility made a similar mistake.
On Windows, files in use can't be deleted. hiberfil.sys can't be deleted because it is held open by the OS, not because of specific protection. It is protected against regular users from deleting it, not that it maters much. NTLDR can be deleted because it's no longer in needed after control is passed to the kernel, so it's not in use. It still requires admin access in the default config to delete.
If you really want it to be *impossible* to delete system files on Windows then start complaining to Microsoft. If they implement the feature I'm sure you won't join the complainers about how MS is taking more control away.
Ummm, third parties, cannot directly access the video hardware on Windows or Linux either, but apps running on them seem to be able to use the provided video APIs just fine.
Read the up on the problems VLC and others have on OSX. Yes the APIs are there, but they DON'T ACTUALLY WORK!
Flash, VLC and the rest don't need direct hardware access on OSX, just playback APIs that aren't crippled.
No video acceleration on OSX means no video acceleration AT ALL. No H.264, no MPEG2, no overlays, nothing. Lack of overlay support is what kills performance even on older Macs. All video apps basically have to waste tonnes of CPU just manually moving the pixels around instead of the video card doing it. Overlay support has been around for over 20 years and is critical to smooth video playback but OSX doesn't allow anything to access it.
As to why apps don't use Quicktime? Maybe because it sucks and even then doesn't work for non approved formats. See my point about perian above. Non official Quicktime plugins or formats don't get accel, even within the Quicktime framework. Since it doesn't work for everything that kind of defeats the point of using VLC in the first place.
I'm not denying Flash sucks and could be made significantly faster. However, the lack of hardware acceleration on OSX just makes a bad situation much much worse.
While Flash does need a lot more optimization and is slow on all platforms, it is mainly Apple's fault it is so slow on OSX. No third party programs can us video acceleration on OSX. Only Quicktime and approved plugins can use hardware acceleration.
Try running a video in VLC on Windows or Linux and then compare it to VLC on OSX. On OSX it will use a lot more CPU time than the other two. Not as bad as flash, but still way worse than on other OSes. Take a look at the VLC dev forms sometime and you'll see that hardware accel for third parties is impossible on OSX.
Even third party Quicktime plugins can't use acceleration. Use perrian to add MKV support to quicktime and watch H.264 videos crawl. Repackage that same H.264 stream into a quicktime container and it plays fine.
Flash for OSX sucks because Apple does not provide proper working video acceleration APIs. Nothing outside of blessed Quicktime components can actually use video acceleration. Don't believe me? Go browse the VLC forms, you'll see they have the same problems. No third parties can use full accel on OSX.
VMs get around it by kernel hooks into the video hardware. Unless you want something as unstable as Flash using kexts then the blame for poor performance on OSX lies solely at Apple's feet.
Re:your first sentence is technically flawed
on
Ubuntu on a Dime
·
· Score: 5, Interesting
Given that the 4.77 MHz 8088 needed several cycles just to calculate a memory address, a hypervisor being "fucking slow" is a gross understatement.
While you could have separate users there would be no security between them on a 8088 or other CPU without privilege levels. Non-root accounts would be in name only. There would be nothing stopping a regular user from writing a 0 at the right place in memory and making itself root. Or simply writing garbage all over the disk or any number of things that proper user security prevents.
Re:your first sentence is technically flawed
on
Ubuntu on a Dime
·
· Score: 1
The Sun systems had extra chips to implement the MMU that real UNIX needed. Those would have been far to expensive to implement in the IBM PC. The bare 68000 could not do it.
As to Xenix , you had "UNIX" with all the stability and security of DOS.
Care to name the CPU that did have protection in 1981 and wouldn't have sent the already expensive PC's price skyrocketing?
Re:your first sentence is technically flawed
on
Ubuntu on a Dime
·
· Score: 5, Informative
This has nothing to do with the skills (or lack there of) of programmers in 1982, but everything with the CPU features available. The 8088 and anything else IBM might have used did not support memory protection or any form of privilege separation. UNIX needs those features in hardware to run. Some early UNIX workstations added custom support chips to implement those features on the simple CPUs, but that would have priced the IBM PC out of its market.
Yes, there are some specialized UNIX variants that will run on such limited hardware, but they don't support proper secuirty simply because they can't
The original versions of Windows didn't have any memory protection or any concept of security or separate users. It wasn't designed to.
We looked into this, but the problem is that most of the apps are launched from client web sites that we have no control over. If the specific buggy JVM is hidden from the browser than any apps that need it fail. As it stand now malware has several buggy JVMs to chose from as almost no apps use the same version as any of the others.
The best we can do is lock down the machines as much as possible so any malware that gets launched doesn't have rights to infect anything other than the user's profile. A reboot and a profile delete usually clears them up.
Java has security bugs just like everything else. I don't know if it has more or less than average. The problem is that so many Java apps require specific JVM versions so you are stuck with buggy versions.
I'm a desktop admin who has to support running many different Java apps, most provided by our clients. While a few will work with whatever JVM as long as it's new enough, most require a specific version. It's not just dumb apps that have a hard coded version check. Some don't check yet still fail with the wrong JVM version, often in odd ways. For example we have one app that if run on the wrong version, even one patch release different, will no longer have working cut and paste. I can run the apps just fine across Windows or Linux, but the JVM must be the right version.
The problem is now the most common infection on our machines, despite many still running IE6, is Vundo variants that get in through the JVM.
What the hell are you talking about? The north bridge does not contain most of the CPU. Yes, the Atom is often paired with an inefficient north bridge which requires a fan, but that's it. If what you said was true then Nvidia's ION (which replaces the north bridge) would be impossible.
The newer Pineview Atoms do combine the Northbridge and CPU. Again this is nothing speical or any trickery, AMD has been doing this for years. You would again be wrong in your description if it was a Pineview in that the small chip is just the south bridge, not the CPU.
HDMI can transmit up to 8 channels of uncompressed high resolution audio. SPDIF can transmit 4 channels uncompressed, but two is much more common in reality. Multi-channel requires compression like AC3 or DTS.
As my other post states, DVI can carry the same audio as HDMI, but I don't know if the Mac Mini supports it.
DVI most certainly can carry the same audio that HDMI does. It's not overly common, but some video cards do have HDMI audio support with only DVI ports. I don't know if the Mac Mini's DVI port supports this or not.
The GP is right, Spinrite does not and can not do most of what it claims on a modern HD. The only potentially useful thing it does is re-read sectors up to hundreds of times, but there is safer software that does the same thing.
More importantly, Spinrite can be downright dangerous to your data. Spinrite writes any data it recovers TO THE SAME DRIVE! It can very easily overwrite other data you want to keep and/or lose the recovered data again because the drive isn't stable enough to hold it reliably. Not writing to the damaged media is data recovery 101 and Spinrite fails badly.
The current version of OSX can run apps as far back as 2001. Apple does not provide any official way of running apps older than that.
The current 64 bit versions of Windows can run apps as far back as 1993. Microsoft provides an official way of running even older apps (XP Mode). 32 bit Windows can often run 16 bit apps without the emulator.
Microsoft has lots to fault them for, but their record on backwards compatibility is WAY better than Apple's.
See above. The 604 and other PPC ships were only good competitors in Apple's marketing. The few actual SPEC benchmarks for the PPC show the P-Pro and above are clearly faster.
Sycraft-fu's memories are correct. There's a surprising lack of actual benchmarks for the older PPC chips (gee, I wonder why), but the few published PPC SPEC results show the P-Pro handily trounces the 604e. The P1 vs the 601 was a closer race, but still in Intel's favor. The P-Pro and beyond are all "RISC like" internally and gave Intel the clear lead.
The Power PC 601 may have been "released" earlier, but the first PowerMacs didn't actually come out until a year after the Pentium. By that time any speed advantage was gone. Other than a very brief period where the 604 was out before the P-Pro, X86 was always the faster chip. Yeah, there were a few apps where Ali-Vec cleaned up, but general purpose performance was almost always in X86's favor. Intel had the money to put into R&D and it shows.
The emulation thing may be true, but if Apple had done a proper transition like they did with the PPC to Intel one then it wouldn't have been a big issue. Old 68K apps would have been a bit slower but the OS and re-complied apps would have benified from the faster and cheaper X86 chips. Apple needed good emulation because they didn't port their OS properly still had massive chunks of it still running in 68K and then emulated.
The Power PC was a failure because it gave Apple slower computers despite their marketing claims. PPC was only needed because Apple couldn't write a proper OS at the time and needed the best emulation possible.
The Geoport first came out in Apple's 68040 models. Basically lower end 486 speeds.
The first Winmodems didn't appear until well into the Pentium era for PCs. So in addition to having better multitasking in Windows, Winmodems had a lot more CPU power to work with and thus less impact on the host system.
Not in my experience. We still have IE6 on over 90% of the desktops where I work, mostly due to legacy apps. While we do get the occasional problem with it, 90%+ of the drive by downloads are from buggy JREs from Sun that we can't upgrade due to other legacy apps. Most of the Java apps are still far newer than the IE6 ones and less likely to be replaced anytime soon.
Most of the remaining drive by downloads are Adobe Flash or Reader related. IE6 is really a small problem and cost in comparison.
I'll believe it when I see it. If it's on par with past ARM chips then it won't be even close to x86 speed wise.
I did an informal browsing test of a 400 MHz ARM (N800) VS a P2 400. Same RAM, both using wireless, both using mozilla based browsers in Linux. The P2 absolutely destroyed the ARM in browsing speed. It wasn't even close, the x86 chip was faster in every way.
Slashdot Mirror
You can delete the kernel, system libraries or any other vital file on Linux too and it won't stop you. You need root you say? You need admin on Windows to delete them.
Non-admin accounts on Windows can't delete start up files unless someone has screwed with the default permissions. Any sane corporate environment is not giving admin rights to the general users.
System utilities like AV programs need full access to do their jobs so of course they have rights to do stupid things. Same thing could happen on Linux if a package manager or other system utility made a similar mistake.
On Windows, files in use can't be deleted. hiberfil.sys can't be deleted because it is held open by the OS, not because of specific protection. It is protected against regular users from deleting it, not that it maters much. NTLDR can be deleted because it's no longer in needed after control is passed to the kernel, so it's not in use. It still requires admin access in the default config to delete.
If you really want it to be *impossible* to delete system files on Windows then start complaining to Microsoft. If they implement the feature I'm sure you won't join the complainers about how MS is taking more control away.
Ummm, third parties, cannot directly access the video hardware on Windows or Linux either, but apps running on them seem to be able to use the provided video APIs just fine.
Read the up on the problems VLC and others have on OSX. Yes the APIs are there, but they DON'T ACTUALLY WORK!
Flash, VLC and the rest don't need direct hardware access on OSX, just playback APIs that aren't crippled.
No video acceleration on OSX means no video acceleration AT ALL. No H.264, no MPEG2, no overlays, nothing. Lack of overlay support is what kills performance even on older Macs. All video apps basically have to waste tonnes of CPU just manually moving the pixels around instead of the video card doing it. Overlay support has been around for over 20 years and is critical to smooth video playback but OSX doesn't allow anything to access it.
As to why apps don't use Quicktime? Maybe because it sucks and even then doesn't work for non approved formats. See my point about perian above. Non official Quicktime plugins or formats don't get accel, even within the Quicktime framework. Since it doesn't work for everything that kind of defeats the point of using VLC in the first place.
I'm not denying Flash sucks and could be made significantly faster. However, the lack of hardware acceleration on OSX just makes a bad situation much much worse.
While Flash does need a lot more optimization and is slow on all platforms, it is mainly Apple's fault it is so slow on OSX. No third party programs can us video acceleration on OSX. Only Quicktime and approved plugins can use hardware acceleration.
Try running a video in VLC on Windows or Linux and then compare it to VLC on OSX. On OSX it will use a lot more CPU time than the other two. Not as bad as flash, but still way worse than on other OSes. Take a look at the VLC dev forms sometime and you'll see that hardware accel for third parties is impossible on OSX.
Even third party Quicktime plugins can't use acceleration. Use perrian to add MKV support to quicktime and watch H.264 videos crawl. Repackage that same H.264 stream into a quicktime container and it plays fine.
The first NT port was actually for the i860.
Flash for OSX sucks because Apple does not provide proper working video acceleration APIs. Nothing outside of blessed Quicktime components can actually use video acceleration. Don't believe me? Go browse the VLC forms, you'll see they have the same problems. No third parties can use full accel on OSX.
VMs get around it by kernel hooks into the video hardware. Unless you want something as unstable as Flash using kexts then the blame for poor performance on OSX lies solely at Apple's feet.
Given that the 4.77 MHz 8088 needed several cycles just to calculate a memory address, a hypervisor being "fucking slow" is a gross understatement.
While you could have separate users there would be no security between them on a 8088 or other CPU without privilege levels. Non-root accounts would be in name only. There would be nothing stopping a regular user from writing a 0 at the right place in memory and making itself root. Or simply writing garbage all over the disk or any number of things that proper user security prevents.
The Sun systems had extra chips to implement the MMU that real UNIX needed. Those would have been far to expensive to implement in the IBM PC. The bare 68000 could not do it. As to Xenix , you had "UNIX" with all the stability and security of DOS.
Care to name the CPU that did have protection in 1981 and wouldn't have sent the already expensive PC's price skyrocketing?
This has nothing to do with the skills (or lack there of) of programmers in 1982, but everything with the CPU features available. The 8088 and anything else IBM might have used did not support memory protection or any form of privilege separation. UNIX needs those features in hardware to run. Some early UNIX workstations added custom support chips to implement those features on the simple CPUs, but that would have priced the IBM PC out of its market.
Yes, there are some specialized UNIX variants that will run on such limited hardware, but they don't support proper secuirty simply because they can't
The original versions of Windows didn't have any memory protection or any concept of security or separate users. It wasn't designed to.
We looked into this, but the problem is that most of the apps are launched from client web sites that we have no control over. If the specific buggy JVM is hidden from the browser than any apps that need it fail. As it stand now malware has several buggy JVMs to chose from as almost no apps use the same version as any of the others.
The best we can do is lock down the machines as much as possible so any malware that gets launched doesn't have rights to infect anything other than the user's profile. A reboot and a profile delete usually clears them up.
Java has security bugs just like everything else. I don't know if it has more or less than average. The problem is that so many Java apps require specific JVM versions so you are stuck with buggy versions.
I'm a desktop admin who has to support running many different Java apps, most provided by our clients. While a few will work with whatever JVM as long as it's new enough, most require a specific version. It's not just dumb apps that have a hard coded version check. Some don't check yet still fail with the wrong JVM version, often in odd ways. For example we have one app that if run on the wrong version, even one patch release different, will no longer have working cut and paste. I can run the apps just fine across Windows or Linux, but the JVM must be the right version.
The problem is now the most common infection on our machines, despite many still running IE6, is Vundo variants that get in through the JVM.
What the hell are you talking about? The north bridge does not contain most of the CPU. Yes, the Atom is often paired with an inefficient north bridge which requires a fan, but that's it. If what you said was true then Nvidia's ION (which replaces the north bridge) would be impossible.
The newer Pineview Atoms do combine the Northbridge and CPU. Again this is nothing speical or any trickery, AMD has been doing this for years. You would again be wrong in your description if it was a Pineview in that the small chip is just the south bridge, not the CPU.
HDMI can transmit up to 8 channels of uncompressed high resolution audio. SPDIF can transmit 4 channels uncompressed, but two is much more common in reality. Multi-channel requires compression like AC3 or DTS.
As my other post states, DVI can carry the same audio as HDMI, but I don't know if the Mac Mini supports it.
DVI most certainly can carry the same audio that HDMI does. It's not overly common, but some video cards do have HDMI audio support with only DVI ports. I don't know if the Mac Mini's DVI port supports this or not.
Roadkil's unstoppable copier. Works on both Windows and Linux
http://www.roadkil.net/program.php?ProgramID=29
dd_rhelp works with dd_rescue to try to recover from disks with bad sectors.
http://www.kalysto.org/utilities/dd_rhelp/index.en.html
The GP is right, Spinrite does not and can not do most of what it claims on a modern HD. The only potentially useful thing it does is re-read sectors up to hundreds of times, but there is safer software that does the same thing.
More importantly, Spinrite can be downright dangerous to your data. Spinrite writes any data it recovers TO THE SAME DRIVE! It can very easily overwrite other data you want to keep and/or lose the recovered data again because the drive isn't stable enough to hold it reliably. Not writing to the damaged media is data recovery 101 and Spinrite fails badly.
What are you talking about?
The current version of OSX can run apps as far back as 2001. Apple does not provide any official way of running apps older than that.
The current 64 bit versions of Windows can run apps as far back as 1993. Microsoft provides an official way of running even older apps (XP Mode). 32 bit Windows can often run 16 bit apps without the emulator.
Microsoft has lots to fault them for, but their record on backwards compatibility is WAY better than Apple's.
See above. The 604 and other PPC ships were only good competitors in Apple's marketing. The few actual SPEC benchmarks for the PPC show the P-Pro and above are clearly faster.
Sycraft-fu's memories are correct. There's a surprising lack of actual benchmarks for the older PPC chips (gee, I wonder why), but the few published PPC SPEC results show the P-Pro handily trounces the 604e. The P1 vs the 601 was a closer race, but still in Intel's favor. The P-Pro and beyond are all "RISC like" internally and gave Intel the clear lead.
The Power PC 601 may have been "released" earlier, but the first PowerMacs didn't actually come out until a year after the Pentium. By that time any speed advantage was gone. Other than a very brief period where the 604 was out before the P-Pro, X86 was always the faster chip. Yeah, there were a few apps where Ali-Vec cleaned up, but general purpose performance was almost always in X86's favor. Intel had the money to put into R&D and it shows.
The emulation thing may be true, but if Apple had done a proper transition like they did with the PPC to Intel one then it wouldn't have been a big issue. Old 68K apps would have been a bit slower but the OS and re-complied apps would have benified from the faster and cheaper X86 chips. Apple needed good emulation because they didn't port their OS properly still had massive chunks of it still running in 68K and then emulated.
The Power PC was a failure because it gave Apple slower computers despite their marketing claims. PPC was only needed because Apple couldn't write a proper OS at the time and needed the best emulation possible.
The Geoport first came out in Apple's 68040 models. Basically lower end 486 speeds.
The first Winmodems didn't appear until well into the Pentium era for PCs. So in addition to having better multitasking in Windows, Winmodems had a lot more CPU power to work with and thus less impact on the host system.
Not in my experience. We still have IE6 on over 90% of the desktops where I work, mostly due to legacy apps. While we do get the occasional problem with it, 90%+ of the drive by downloads are from buggy JREs from Sun that we can't upgrade due to other legacy apps. Most of the Java apps are still far newer than the IE6 ones and less likely to be replaced anytime soon.
Most of the remaining drive by downloads are Adobe Flash or Reader related. IE6 is really a small problem and cost in comparison.
I'll believe it when I see it. If it's on par with past ARM chips then it won't be even close to x86 speed wise.
I did an informal browsing test of a 400 MHz ARM (N800) VS a P2 400. Same RAM, both using wireless, both using mozilla based browsers in Linux. The P2 absolutely destroyed the ARM in browsing speed. It wasn't even close, the x86 chip was faster in every way.