Perhaps it is "my own setup," the PC is getting a little long in the tooth. But it's not lacking for CPU power. Something like Photoshop might run OK. The slowdown I've noticed excessive disk thrashing from Azureus's RAM consumption and monopolization of the system cache. Tasks which require a lot (or even a little) disk access get quite sluggish. ZIP archiving, usenet decodes, even simple web browsing - things which the PC usually does fairly snappily - become painful. And it gets worse when seeding multiple torrents.
I've got no bone to pick with Java; I'm just pointing out that it still compares unfavorably with precompiled code in real-world, end-user, desktop-type applications, particularly when RAM is tight. If you have a monster desktop, you may not notice, and if you're writing server code, you may not care. That doesn't mean Java is efficient.
One word. Bollocks. I have Azureus running right now. [On a Linux PC with 2GB of RAM].
Do you really feel that your experience running Linux in 2048MB somehow negates my experience running Windows in 512MB?
Perhaps there are JVM tweaks that might improve the situation. I've never looked. I'm not interested. Why should I have to resort to such things? I've switched to uTorrent, which does everything I want in about 1/20th the RAM, no tweaking required.
Um, you did see what the article is about didn't you? Perhaps you should try it out.
Other posters here have commented that that the servers offering up 30+MB of game assets per user are completely borked by legions of Slashdotters. Plus, I'm at work. I'd love to give this a go, but this is a bad moment.
If you had some office-work, code-editing type applications in mind, maybe I'd try those, though.
Even with 512MB of RAM, Azureus (the hugely popular Java-based BitTorrent client) takes forever to start up, responds sluggishly to user input, and sucks down so much RAM that the Windows PC it's running on is nearly useless for any other task. This isn't simply the nature of BitTorrent - other clients run far more smoothly.
Maybe there are reasons for this that aren't directly related to Java. Maybe Azureus just isn't very well-written, or maybe it's just feature-bloated. Maybe the Windows JVM just stinks.
But in any case, the common perception of Java applications as being slow and ponderous is one that Java applications have earned - there are actual reasons, based on real-world experiences, that cause people to feel this way. That has nothing to do with some pig-headed resistance to change.
Rather than railing against the Java-haters, why not point out some useful, slick, fast Java-based applications? I'd love to see some. Every one that I've tried so far has been a disaster in one way or another. I honestly want to like Java. I like the language, I love the concept - it's the real-world experience with it that I have a problem with.
The Silverado 1500 Hybrid, now with limited availability in all 50 states, is offered as an Extended Cab in two- and four-wheel drive...
That the GM site says it doesn't mean any of it's true, of course.
The Silverado sounds like it's strictly an idle-stop system, anyway. It doesn't use stored electricity for propulsion at all, ever. Stored electricity is only used to run the giant starter motor, which gets the big V-8 going in a hurry when the stoplight turns green. So "running on the batteries almost all the time while plowing" isn't happening, at least, not this model year.
In fact, if the idle-stop system doesn't get a chance to kick in during snowplowing (and it probably wouldn't), then this truck might actually have slightly worse fuel consumption, because it's likely to be heavier than the standard model.
In most cases, diesel-electric drivetrains are used when building a mechanical transmission for the vehicle in question (locomotive, giant mining truck, etc) is exceptionally difficult/expensive. In some cases (diesel submarines, some ships) the flexibility and control of electric propulsion is a compelling reason to go diesel-electric.
But the electric steps, like all energy conversions, always waste energy, and plain old mechanical diesel is usually more efficient. If someone developed a cheap, reliable mechanical transmission for locomotives, we'd probably eventually see a switch to diesel-only locomotives, just as we have diesel trucks and cars.
Rather than the automotive engineers following the lead of the rail engineers, the reverse is happening.
Thompson is a Grade A asshat, and it's easy for anyone familiar with video games, with his long-term crusade, or with this episode in particular to see that. But we're not Thompson's intended audience; he doesn't care if we know he's an asshat.
If this story draws any mainstream attention, you know how it will look when the news bobbleheads summarize:
"Pro-family activist lawyer harrassed long-distance by violent video-game-addicted L337 H4XX0R punks! Are YOUR kids safe from internet preadators?"
I've downloaded every major FireFox release, from 0.6 or so, and tried each of them out for a while, but I always come back to Mozilla in the end.
It seems to be more stable for me, and I actually use most of the parts of it at least occaisionally. If you leave Mozilla Mail running all the time (which one tends to do with mail), then you can get a browser/composer/IRC window fast, much snappier than FireFox startup. It seems there's always a few fiddly little settings (like turning off animated.GIFs) that are a snap to change in Mozilla but difficult or impossible in FireFox. FireFox is great for my parents, but the Mozilla suite is great for me.
Well for some reason I thought you were testing cached reads and buffered writes, not cached reads and cached writes. My goof. In any case, my objections to this "test" stand.
This isn't a serious way to get any indication of the performance of a flash-based HD replacement.
The SD equipment you're testing is very different from a solid-state disk system, even if the basic flash technology that actually keeps the bits is the same. The SD interface was designed to be tiny, not to be blazing fast. And the SD card probably contains only a single flash part, whereas a solid-state disk unit is likely able to read from or write to many flash parts in parallel. It wouldn't be fair to condemn all magnetic systems as slow based on the performance of a Microdrive unit, and it isn't fair to condemn all flash systems as slow based on the performance of this SD card.
Also important is that you're testing cached reads and buffered writes, which might be useful system metrics but tell you nothing about the mass-storage hardware in isolation. The whole purpose of caching/buffering is to hide the timing characteristics of the underlying storage. If the system software and device drivers supply a large system RAM buffer for HD writes but not for USB mass storage devices, then one would expect slower USB writing, even if both interfaces were actually ultimately connected to the same mass storage hardware.
In many real-world applications, it's seeks, and not the reads or writes themselves, that consume the most time. Flash obviously has it all over mechanical systems when it comes to seek times, and flash-based HD replacements are generally specified very competitively with real HDs when it comes to sustained transfer speeds. This one claims 44MB/s sustained writing - considerably more than whatever your buffer-obscured HD is actually capable of, I'll wager.
This method requires a lot of compressed air, and ultimately, a lot of energy. If electricity "is not an option," (presumeably because of remoteness from a reliable grid) then where is the energy to make the compressed air coming from?
Because it would be far more efficient to just hook the energy source right up to a conventional refrigeration compressor, surely.
All in all, it sounds to me like the Sun Frost people have a better plan, as far as sunny places go, at least.
Replacing disk with flash RAM is not feasible: flash isn't fast enough, and doesn't survive enough re-writes to the same blocks.
It's not only feasible, it's been done. It's horrifically expensive, but it works. A "wear leveling" algorithm is used to ensure the same flash cells aren't erased and re-written continuously. Heck, even the flash keychain drives and digital camera cards do that. No, it probably won't hold up to as many write cycles as a magnetic disk will, but writes are much less common than reads, especially in some database and web applications. The drive doesn't need to last forever anyway, since the computer it's part of won't either. I've heard that these guys have had one of their flash drives on a continuous rewrite cycle for a few years now - no errors yet.
Where do you get the notion that flash is slow? It's slow compared to RAM, but it's way faster than a hard disk. That's one of the selling points of these things.
Microsoft's habit of not letting anyone see all of their source code means that any system built on a Microsoft OS cannot undergo a real safety audit. MS systems are inherently unsuited to avionics and the like for this reason, their quality or capabilities aside.
LED technology gets me excited because it's so efficient.
LEDs make super-efficient colored lights - i.e., indicators on electronic gear, traffic signals, automotive brake and turn signals, etc. That's partly because the colored LEDs put out many lumens per watt, but it's also largely because no colored filter (which wastes 60-80% of the light produced) is needed with colored LEDs.
But even the best white LEDs are only slightly more efficient than typical 100-year-old-tech incandescent bulbs, and (so far, at least) far less efficient than older tech like flourescents and sodium lamps. White LEDs have become popular in flashlights lately because they have other characteristics that make them very good at that specialized task, not because they're terribly efficient.
Yeah, I haven't used it much, but 7-Zip looks pretty neat. Besides better compression with.zip compatibility, it looks like 7-Zip's native.7z format directly supports solid archives - I imagine that would give better results yet.
Absolutely right. Tar just concatenates all the files to be archived, so that the following gzip step only operates on one file and only creates one compression dictionary. That means.tar.gz files are always solid archives. The 1st non-compressed ZIP file in the double-zip method is analogous to the tar process.
I believe RAR does what they call "solid archiving," which means that a single compression dictionary is created for the entire archive.
ZIP doesn't do that; each file in a ZIP archive is compressed individually, with a separate compression dictionary. That hurts the compression ratio for ZIP archives that contain many files, particularly many small files, particularly many similar small files, like source code, for example. But it does mean that archive operations (like extracting or updating individual files or and adding files to or removing files from an archive) are fast and simple.
It's possible, in some cases, to dramatically increase the compression ratio ZIP achieves by ZIPing twice, emulating the "solid archive" method. (This is also what using.tar.gz does.) For the first ZIP, specify "no compression" (sometimes called "archive only") for the degree of compression desired. No compression dictionary will be created. Then ZIP that uncompressed ZIP file, using maximum compression this time. Since you're compressing just one file, only a single compression dictionary will be created. Especially for files that have a lot of similarity to each other (like human-language text or computer-language text), there's a big savings in using a single dictionary.
I tried this with some source code archives and reduced ZIPs from (IIRC) ~150KB to ~90KB. Not really a worthwhile absolute savings, these days, but a huge improvement, percentage-wise. I also tried this with the Windows distribution of Emacs (which is distributed as.tar.gz.). ZIP managed ~17MB, double-ZIP managed ~12MB - slightly smaller than the.tar.gz distro, in fact.
Doing this is a little clumsy, but it can offer a much-improved compression ratio in a format that virtually every Windows user already has access to.
Read through the thread and look at all the great commentary on and links to alternative archiving programs. Many of them are gratis, and a few are even F/OSS.
Whatever the original intent of the post, the discussion has created in this thread a useful resource for fans of non-commercial software. That can't be all bad, can it?
There are 2 groups of people here. Those who know right from wrong...
I will concede that there is likely a small group of individuals that overlap into both groups...
Have you got anything besides strength-of-conviction and high-horse moralizing going on here? Why are you so sure that this is the case? Have any numbers? Any studies?
Or are you just certain that your own experience and circle of friends is a perfect reflection of the entire planet's population?
This "pirates aren't customers" idea is the industry line, after all. And the industry isn't exactly known for its honesty. The content providers have habitually distorted and misinterpreted their own sales data, have been found guilty of countless payola scandals and price fixing, use contract policies that are actually illegal in other businesses, etc, etc and on and on. Why would you believe a single word these people say, at this point?
Your memory does not serve you well. For a start it's winfile, not fileman
My memory's fine, thanks. The EXE was indeed WINFILE.EXE, but the program's title bar read "File Manager," and I didn't think "Fileman" is an unreasonable abbrev.
I'm pretty sure double clicking on an executable (including a pif) in "file manager" would start the executable.
If you're only pretty sure, it can't have been something you were tempted to try very often. Besides, this may not matter, because PIF filenames were not required to bear any relationship whatsoever to the programs they were associated with, and were in any case limited to 8 characters, whereas the Program Manager icons were allowed to have reasonable names. WINFILE.EXE couldn't really be said to be a reasonable replacement for the Program Manager, even for a geek, let alone for Joe User.
Setting up a pif file was achieved using pifedit. It had an icon the Main program group, but was independent of Program Manager itself.
I had forgotten about that. One more reason to hate the awful, stupid Program Manager. It couldn't even do the most basic management of programs. They should have just called it the Icon Manager or something - that's really all it could do.
As I said elsewhere in this thread, if you liked the program manager, you can get the same style (except much improved) funtionality with some ordinary filesystem folders and some shortcut files. That kind of flexibility and customizability is one thing MS did right.
As I tried to point out elsewhere on this thread, the intended function of Start / Desktop / Explorer may be different, but they're all providing specialized views of the same underlying filesystem now. A filesystem the user can manipulate, customize, and otherwise use however he sees fit. The duality, such as it is, is now only a convention, a convenience, a frame of mind, not a technical necessity.
If you liked the Progman style, you can just set up your app-start icons in desktop folders, and you've got essentially everything Progman could ever do. Except you can now mix documents in with your app-start icons if the whim strikes, and you could even write scripts to organize, back up, modify, or migrate your application icons if you want, because they're just files.
Well, maybe. The Start menu is just "syntactic sugar," so to speak. It's just a pretty face on top of part of the same filesystem Explorer shows. The "duality" it presents isn't even skin-deep; you can stick documents in the Start menu and you can launch applications from the Explorer. If you were so inclined, you could make today the last day you ever touch the Start menu, yet give up zero functionality and only a debateable amount of convenience.
The old Progman/Fileman duality couldn't do stuff like that. Its duality reflected the underlying reality of how Win3.x worked - it wasn't just a UI design choice. Many applications needed.PIF files, and the Progman was the only part of the system that could associate an icon with a.PIF and ultimately with an.EXE. Meanwhile even the smallest file-manipulation task (like renaming or deleting a single file) required the Fileman. There was no way to use the PC as a desktop computer without being familiar with and using both, and frequently one ended up switching back and forth over and over again.
Usability, maybe, the Win3.x UI, with the strange Program Manager / File Manager duality, wasn't anything to be proud of.
Stability, though? It wasn't my experience that Win95 was stable at all. In fact, where Win3.x was at least learnably-unstable (you would learn that certain applications or actions were likely to crash or to crash Windows) Win95 was randomly-unstable, crashing in non-repeatable, unexplainable ways.
Windows Workstation NT 4.0 was the first Microsoft OS I used that could function as a desktop system for weeks at a time without crashing. I think that was the big leap forward in stability.
Slashdot Mirror
Perhaps it is "my own setup," the PC is getting a little long in the tooth. But it's not lacking for CPU power. Something like Photoshop might run OK. The slowdown I've noticed excessive disk thrashing from Azureus's RAM consumption and monopolization of the system cache. Tasks which require a lot (or even a little) disk access get quite sluggish. ZIP archiving, usenet decodes, even simple web browsing - things which the PC usually does fairly snappily - become painful. And it gets worse when seeding multiple torrents.
I've got no bone to pick with Java; I'm just pointing out that it still compares unfavorably with precompiled code in real-world, end-user, desktop-type applications, particularly when RAM is tight. If you have a monster desktop, you may not notice, and if you're writing server code, you may not care. That doesn't mean Java is efficient.
All these replies to my post (which honestly wasn't intended as flame-bait) and only one person actually links to a good Java app. Marvelous.
I've bookmarked this and I'll definitely give it a try. Thanks!
One word. Bollocks. I have Azureus running right now. [On a Linux PC with 2GB of RAM].
Do you really feel that your experience running Linux in 2048MB somehow negates my experience running Windows in 512MB?
Perhaps there are JVM tweaks that might improve the situation. I've never looked. I'm not interested. Why should I have to resort to such things? I've switched to uTorrent, which does everything I want in about 1/20th the RAM, no tweaking required.
Um, you did see what the article is about didn't you? Perhaps you should try it out.
Other posters here have commented that that the servers offering up 30+MB of game assets per user are completely borked by legions of Slashdotters. Plus, I'm at work. I'd love to give this a go, but this is a bad moment.
If you had some office-work, code-editing type applications in mind, maybe I'd try those, though.
Even with 512MB of RAM, Azureus (the hugely popular Java-based BitTorrent client) takes forever to start up, responds sluggishly to user input, and sucks down so much RAM that the Windows PC it's running on is nearly useless for any other task. This isn't simply the nature of BitTorrent - other clients run far more smoothly.
Maybe there are reasons for this that aren't directly related to Java. Maybe Azureus just isn't very well-written, or maybe it's just feature-bloated. Maybe the Windows JVM just stinks.
But in any case, the common perception of Java applications as being slow and ponderous is one that Java applications have earned - there are actual reasons, based on real-world experiences, that cause people to feel this way. That has nothing to do with some pig-headed resistance to change.
Rather than railing against the Java-haters, why not point out some useful, slick, fast Java-based applications? I'd love to see some. Every one that I've tried so far has been a disaster in one way or another. I honestly want to like Java. I like the language, I love the concept - it's the real-world experience with it that I have a problem with.
The Silverado 1500 Hybrid, now with limited availability in all 50 states, is offered as an Extended Cab in two- and four-wheel drive...
That the GM site says it doesn't mean any of it's true, of course.
The Silverado sounds like it's strictly an idle-stop system, anyway. It doesn't use stored electricity for propulsion at all, ever. Stored electricity is only used to run the giant starter motor, which gets the big V-8 going in a hurry when the stoplight turns green. So "running on the batteries almost all the time while plowing" isn't happening, at least, not this model year.
In fact, if the idle-stop system doesn't get a chance to kick in during snowplowing (and it probably wouldn't), then this truck might actually have slightly worse fuel consumption, because it's likely to be heavier than the standard model.
In most cases, diesel-electric drivetrains are used when building a mechanical transmission for the vehicle in question (locomotive, giant mining truck, etc) is exceptionally difficult/expensive. In some cases (diesel submarines, some ships) the flexibility and control of electric propulsion is a compelling reason to go diesel-electric.
But the electric steps, like all energy conversions, always waste energy, and plain old mechanical diesel is usually more efficient. If someone developed a cheap, reliable mechanical transmission for locomotives, we'd probably eventually see a switch to diesel-only locomotives, just as we have diesel trucks and cars.
Rather than the automotive engineers following the lead of the rail engineers, the reverse is happening.
Thompson is a Grade A asshat, and it's easy for anyone familiar with video games, with his long-term crusade, or with this episode in particular to see that. But we're not Thompson's intended audience; he doesn't care if we know he's an asshat.
If this story draws any mainstream attention, you know how it will look when the news bobbleheads summarize:
"Pro-family activist lawyer harrassed long-distance by violent video-game-addicted L337 H4XX0R punks! Are YOUR kids safe from internet preadators?"
I've downloaded every major FireFox release, from 0.6 or so, and tried each of them out for a while, but I always come back to Mozilla in the end.
.GIFs) that are a snap to change in Mozilla but difficult or impossible in FireFox. FireFox is great for my parents, but the Mozilla suite is great for me.
It seems to be more stable for me, and I actually use most of the parts of it at least occaisionally. If you leave Mozilla Mail running all the time (which one tends to do with mail), then you can get a browser/composer/IRC window fast, much snappier than FireFox startup. It seems there's always a few fiddly little settings (like turning off animated
id's Doom gave the world WASD, and it stuck forever.
I use RDFG. Gives fast pinkie access to both A and S and still allows you to orient around the bump on F.
Well for some reason I thought you were testing cached reads and buffered writes, not cached reads and cached writes. My goof. In any case, my objections to this "test" stand.
This isn't a serious way to get any indication of the performance of a flash-based HD replacement.
The SD equipment you're testing is very different from a solid-state disk system, even if the basic flash technology that actually keeps the bits is the same. The SD interface was designed to be tiny, not to be blazing fast. And the SD card probably contains only a single flash part, whereas a solid-state disk unit is likely able to read from or write to many flash parts in parallel. It wouldn't be fair to condemn all magnetic systems as slow based on the performance of a Microdrive unit, and it isn't fair to condemn all flash systems as slow based on the performance of this SD card.
Also important is that you're testing cached reads and buffered writes, which might be useful system metrics but tell you nothing about the mass-storage hardware in isolation. The whole purpose of caching/buffering is to hide the timing characteristics of the underlying storage. If the system software and device drivers supply a large system RAM buffer for HD writes but not for USB mass storage devices, then one would expect slower USB writing, even if both interfaces were actually ultimately connected to the same mass storage hardware.
In many real-world applications, it's seeks, and not the reads or writes themselves, that consume the most time. Flash obviously has it all over mechanical systems when it comes to seek times, and flash-based HD replacements are generally specified very competitively with real HDs when it comes to sustained transfer speeds. This one claims 44MB/s sustained writing - considerably more than whatever your buffer-obscured HD is actually capable of, I'll wager.
This method requires a lot of compressed air, and ultimately, a lot of energy. If electricity "is not an option," (presumeably because of remoteness from a reliable grid) then where is the energy to make the compressed air coming from?
Because it would be far more efficient to just hook the energy source right up to a conventional refrigeration compressor, surely.
All in all, it sounds to me like the Sun Frost people have a better plan, as far as sunny places go, at least.
Replacing disk with flash RAM is not feasible: flash isn't fast enough, and doesn't survive enough re-writes to the same blocks.
It's not only feasible, it's been done. It's horrifically expensive, but it works. A "wear leveling" algorithm is used to ensure the same flash cells aren't erased and re-written continuously. Heck, even the flash keychain drives and digital camera cards do that. No, it probably won't hold up to as many write cycles as a magnetic disk will, but writes are much less common than reads, especially in some database and web applications. The drive doesn't need to last forever anyway, since the computer it's part of won't either. I've heard that these guys have had one of their flash drives on a continuous rewrite cycle for a few years now - no errors yet.
Where do you get the notion that flash is slow? It's slow compared to RAM, but it's way faster than a hard disk. That's one of the selling points of these things.
Microsoft's habit of not letting anyone see all of their source code means that any system built on a Microsoft OS cannot undergo a real safety audit. MS systems are inherently unsuited to avionics and the like for this reason, their quality or capabilities aside.
LED technology gets me excited because it's so efficient.
LEDs make super-efficient colored lights - i.e., indicators on electronic gear, traffic signals, automotive brake and turn signals, etc. That's partly because the colored LEDs put out many lumens per watt, but it's also largely because no colored filter (which wastes 60-80% of the light produced) is needed with colored LEDs.
But even the best white LEDs are only slightly more efficient than typical 100-year-old-tech incandescent bulbs, and (so far, at least) far less efficient than older tech like flourescents and sodium lamps. White LEDs have become popular in flashlights lately because they have other characteristics that make them very good at that specialized task, not because they're terribly efficient.
Yeah, I haven't used it much, but 7-Zip looks pretty neat. Besides better compression with .zip compatibility, it looks like 7-Zip's native .7z format directly supports solid archives - I imagine that would give better results yet.
I don't think tar uses any compression...
.tar.gz files are always solid archives. The 1st non-compressed ZIP file in the double-zip method is analogous to the tar process.
Absolutely right. Tar just concatenates all the files to be archived, so that the following gzip step only operates on one file and only creates one compression dictionary. That means
I believe RAR does what they call "solid archiving," which means that a single compression dictionary is created for the entire archive.
.tar.gz does.) For the first ZIP, specify "no compression" (sometimes called "archive only") for the degree of compression desired. No compression dictionary will be created. Then ZIP that uncompressed ZIP file, using maximum compression this time. Since you're compressing just one file, only a single compression dictionary will be created. Especially for files that have a lot of similarity to each other (like human-language text or computer-language text), there's a big savings in using a single dictionary.
.tar.gz.). ZIP managed ~17MB, double-ZIP managed ~12MB - slightly smaller than the .tar.gz distro, in fact.
ZIP doesn't do that; each file in a ZIP archive is compressed individually, with a separate compression dictionary. That hurts the compression ratio for ZIP archives that contain many files, particularly many small files, particularly many similar small files, like source code, for example. But it does mean that archive operations (like extracting or updating individual files or and adding files to or removing files from an archive) are fast and simple.
It's possible, in some cases, to dramatically increase the compression ratio ZIP achieves by ZIPing twice, emulating the "solid archive" method. (This is also what using
I tried this with some source code archives and reduced ZIPs from (IIRC) ~150KB to ~90KB. Not really a worthwhile absolute savings, these days, but a huge improvement, percentage-wise. I also tried this with the Windows distribution of Emacs (which is distributed as
Doing this is a little clumsy, but it can offer a much-improved compression ratio in a format that virtually every Windows user already has access to.
Read through the thread and look at all the great commentary on and links to alternative archiving programs. Many of them are gratis, and a few are even F/OSS.
Whatever the original intent of the post, the discussion has created in this thread a useful resource for fans of non-commercial software. That can't be all bad, can it?
There are 2 groups of people here. Those who know right from wrong...
I will concede that there is likely a small group of individuals that overlap into both groups...
Have you got anything besides strength-of-conviction and high-horse moralizing going on here? Why are you so sure that this is the case? Have any numbers? Any studies?
Or are you just certain that your own experience and circle of friends is a perfect reflection of the entire planet's population?
This "pirates aren't customers" idea is the industry line, after all. And the industry isn't exactly known for its honesty. The content providers have habitually distorted and misinterpreted their own sales data, have been found guilty of countless payola scandals and price fixing, use contract policies that are actually illegal in other businesses, etc, etc and on and on. Why would you believe a single word these people say, at this point?
Your memory does not serve you well. For a start it's winfile, not fileman
My memory's fine, thanks. The EXE was indeed WINFILE.EXE, but the program's title bar read "File Manager," and I didn't think "Fileman" is an unreasonable abbrev.
I'm pretty sure double clicking on an executable (including a pif) in "file manager" would start the executable.
If you're only pretty sure, it can't have been something you were tempted to try very often. Besides, this may not matter, because PIF filenames were not required to bear any relationship whatsoever to the programs they were associated with, and were in any case limited to 8 characters, whereas the Program Manager icons were allowed to have reasonable names. WINFILE.EXE couldn't really be said to be a reasonable replacement for the Program Manager, even for a geek, let alone for Joe User.
Setting up a pif file was achieved using pifedit. It had an icon the Main program group, but was independent of Program Manager itself.
I had forgotten about that. One more reason to hate the awful, stupid Program Manager. It couldn't even do the most basic management of programs. They should have just called it the Icon Manager or something - that's really all it could do.
As I said elsewhere in this thread, if you liked the program manager, you can get the same style (except much improved) funtionality with some ordinary filesystem folders and some shortcut files. That kind of flexibility and customizability is one thing MS did right.
As I tried to point out elsewhere on this thread, the intended function of Start / Desktop / Explorer may be different, but they're all providing specialized views of the same underlying filesystem now. A filesystem the user can manipulate, customize, and otherwise use however he sees fit. The duality, such as it is, is now only a convention, a convenience, a frame of mind, not a technical necessity.
If you liked the Progman style, you can just set up your app-start icons in desktop folders, and you've got essentially everything Progman could ever do. Except you can now mix documents in with your app-start icons if the whim strikes, and you could even write scripts to organize, back up, modify, or migrate your application icons if you want, because they're just files.
Well, maybe. The Start menu is just "syntactic sugar," so to speak. It's just a pretty face on top of part of the same filesystem Explorer shows. The "duality" it presents isn't even skin-deep; you can stick documents in the Start menu and you can launch applications from the Explorer. If you were so inclined, you could make today the last day you ever touch the Start menu, yet give up zero functionality and only a debateable amount of convenience.
.PIF files, and the Progman was the only part of the system that could associate an icon with a .PIF and ultimately with an .EXE. Meanwhile even the smallest file-manipulation task (like renaming or deleting a single file) required the Fileman. There was no way to use the PC as a desktop computer without being familiar with and using both, and frequently one ended up switching back and forth over and over again.
The old Progman/Fileman duality couldn't do stuff like that. Its duality reflected the underlying reality of how Win3.x worked - it wasn't just a UI design choice. Many applications needed
Usability, maybe, the Win3.x UI, with the strange Program Manager / File Manager duality, wasn't anything to be proud of.
Stability, though? It wasn't my experience that Win95 was stable at all. In fact, where Win3.x was at least learnably-unstable (you would learn that certain applications or actions were likely to crash or to crash Windows) Win95 was randomly-unstable, crashing in non-repeatable, unexplainable ways.
Windows Workstation NT 4.0 was the first Microsoft OS I used that could function as a desktop system for weeks at a time without crashing. I think that was the big leap forward in stability.