I've seen real cases where removing malware has been rather difficult when said malware is already running. Of course those systems actually did have real-time protection, so those times it didn't help. I'd still argue that if you want to fight malware once it's already managed to get itself running on the system, you're fighting a difficult battle -- the malware can interfere with the protection.
I'm not a Mac user but AFAIK Spotlight (as well as other desktop search systems) build and maintain an index of file contents, not only of the file name (as locate does).
Grep of course searches by file contents but the search can take a long time whereas an index would allow the search to be done in a matter of seconds or so. Another thing is that desktop search engines tend to support parsing and indexing the text from many common file types, also binary ones. With grep you may not be as lucky, depending on the file format.
Of course all parts of the desktop search have existed for a long time. It's just a matter of who puts things together, as it so often is.
Putting the gear to neutral or leaving the clutch in may have been a good idea 20 years ago, but nowadays with modern engines the key to saving fuel is actually not doing that.
Now, I'm no expert, but AFAIK with old-style carburetor engines the fuel consumption would be directly affected by the engine RPM. Clearly you could get the RPM quite low by having the engine idle instead of engine braking.
With modern injection engines the fuel flow is controlled by an electronic control unit, and fuel consumption is largely proportional to how much you push the gas pedal. The unit can actually stop the fuel flow completely when the gas pedal is not being pressed (so clearly no acceleration is desired) and the gear is in and the clutch is connected because the movement of the cars (and wheels) keeps the engine moving anyway. Fuel flow and ignition is resumed when needed.
If you disconnect the engine from the wheels by shifting to neutral or leaving the clutch in, you're forcing the control unit to keep feeding fuel into the engine because in that case the engine has to keep idling by its own power.
In cars with a manual transmission, fuel can be saved while the car is coasting in gear. This is because the car's movement is keeping the engine rotating, so there is no need to use fuel for this purpose. Control units on modern transmissions recognize this and stop all fuel flow to the engine when possible. (Automatic transmission cars rely on torque converters, not clutches, to transmit power from the engine to the gearbox, and whereas clutches can transmit power in both directions, torque converters, especially when tuned as they are in cars, are not good at transmitting power in the opposite direction.)
If it's so trivial that any application run under RunAs behaves exactly as if run after logging in interactively as the same user, why do you have to "understand how the system works"?
I really don't know how RunAs works, but if you think about sudo on unix, it's not quite as simple as that. If you've originally logged in as "foo" and then run a command as user "bar" through sudo, does the application you run get the environment (environment variables such as locale settings, home directory location, etc.) from foo or from bar? Or a part from one and another part from the other.
Of course you can make it behave they way that is appropriate for the situation. Perhaps it's the same with RunAs and what you mean by "not understanding" it is exactly that. But "zero difference" between RunAs and an interactive user session may still not quite hold due to such details, and the existence of a magical flag to for applications to detect RunAs is likewise irrelevant.
There's no reason why you couldn't have Python 2.5, 2.6 and 3.0 installed on the same system. You can even supply your own Python environment with your software package if you really want to.
I don't know about Windows, but on *nix you can also specify which interpreter to use at the beginning of the script, and the different versions of the Python interpreter will be available under different names so you can differentiate. For example the default Python version on my system is 2.5, also available as "python2.5". Looks like I still have also 2.4 installed and available as "python2.4".
So, if your code requires Python 2.5, you could just have "#!/usr/bin/env python2.5" at the beginning of your script, and it would be run using the python2.5 command.
If you decide to write for 3.0, of course you'll have to specify 3.0 as a requirement. That happens with any new major versions of pretty much anything. If you take advantage of new features in Java 1.6, obviously you can't deploy it on Java 1.5.
You'll need to have your end-users install Python 3.0 (unless you provide it yourself), but that doesn't mean they couldn't keep also using 2.x for whatever other needs they may have.
I will say the same thing that plagues python has plagued Java and probably hosts of other platforms.
Java? Some things have been broken occasionally in newer releases if you're doing stuff that's exotic enough, but in general I'd say that Java has been pretty damn backwards-compatible all the way. Save for those odd bugs, things written and compiled for Java 1.3 tend to run pretty niftily on 1.6.
Their method is to automagically profile the software when it's compiled. That's obviously something antivirus software doesn't do.
Antivirus software generally doesn't know how a particular piece of legitimate software is supposed to behave. The idea here is that the approach these guys are taking is exactly to try to build a profile for the normal behaviour of the application (or some parts of it, namely the pattern of syscalls). The analysis would be done at compile time, and when the application is being run its pattern of making syscalls would be matched against the known profile. That way the system could supposedly notice a compromised application or service because its pattern would be different than expected.
Also, the method would be powerless against trojans, for example, because they don't work by exploiting vulnerabilities in legitimate software and changing the way it's executed. To me the suggested system seems more like just a potentially boosted intrusion detection system, not general malware-pattern detection, which is what antivirus software does.
How well their profiling would actually work, that I don't know. Theoretically you can't make a complete analysis of all paths the execution of a program could possibly take (for an arbitrary program anyway). Multithreading and inter-process communication might make that even more difficult. But then, maybe it would be just possible to do it for some cases that practically occur with some decent probability.
These guys make a point of avoiding the labour involved in manually building the profile. (FWIW, I don't know about anything service profiling in Vista -- in fact, I had never heard about it -- but your description also sounds somewhat reminiscent of AppArmor.)
The problem is that if there aren't enough people eating the cooked meal, doing so might become rather expensive due to lack of supply or choice.
There's at least one reason why having some share in the market is good also for those who don't require the hand-holding: in the world with commercial interests, there's a lot more support for systems with at least some market share, and that support is often necessary to have a reasonable level of compatibility. Not everything is under the control of the free software community, and that is particularly true if we lack market share.
Is it possible to find hardware that works even with niche operating systems? Yes. Is it a good thing for me if I have fewer choices doing that, potentially forcing me to take a technically inferior or more expensive product just to satisfy the compatibility requirements? No.
The same goes for software: The free software community may be able to cater to most of the needs of its members, also mine. However, there are always situations where I may not have much choice.
Let's say that my company uses a proprietary VoIP solution for some internal communication. I can use Linux for my development work, but if that proprietary application didn't work on my Linux system, I'd be forced to use Windows just because of that. Changing the application to something less proprietary may not be within my power. Using two different operating systems on a daily basis would not be very convenient. While I'd probably end up doing just that, it would also be possible that I or someone else would have to give up using free software due to lack of support from vendors whose products they need to use anyway.
The same goes for other proprietary formats and codecs, although the community has been surprisingly good at supporting many of those (more or less legally) with free implementations. Nevertheless, when most other people use proprietary systems, commercial interests dictate that life is easier also for many of us who wouldn't need the hand-holding itself when there's some degree of commercial interest in the system we use.
Of course there may be valid concern that if we give up too much to accommodate those commercial interests, we lose exactly what we're trying to achieve. I want a (more or less) free system that I can more or less conveniently use, but of course if I give up significant freedom to achieve the usability, I fail to satisfy the other desire I have.
I tend to follow the idea that a 99% free system that is usable for, say, 10% (or 50% or whatever) of people provides more freedom than a 100% free system that is only usable for 1% of people. Where you go over the line of giving up too much freedom is obviously debatable. For me, the current (or former?) state of Ubuntu where they provide proprietary drivers where needed and partially support some proprietary applications is acceptable. That includes the former policy of providing a semi-nonfree Firefox (with the branding making it that way) but without a click-through EULA.
It's very sad that Mozilla has chosen to do this. It's as if they don't consider the distributors their collaborators anymore. However, if I were facing this situation as Canonical, I might have made the same choice even if it wouldn't be easy. Brands are a big thing no matter how much I dislike that, and I can easily see how a newly introduced Ubuntu user will, as his first thing, wonder he can get Firefox if he doesn't find it on his default setup.
Actually, some existing software still does something pretty close to this. In Evince, for example, you can always scroll exactly to the next page regardless of how much of a page is being displayed at the current zoom level by pressing Ctrl+PgDn (and similarly for up). Adobe Reader might behave the same way but I'm not sure. I think OpenOffice.org Impress (the powerpointy thingy) also does that.
I didn't read the patent application, but if TFA has any clue, the only difference between that and the MS 'invention' is that in the latter one the viewer would scroll exactly to the same position in the next/previous page as you were previously viewing on the original page. For example, if you're 1/4 down page n, MS PageDown 2008 (TM) would get you to the position 1/4 down page n+1. The examples I mentioned earlier always give you the beginning of the next/previous page.
Nevertheless, seems trivial. But then, again, I didn't read the patent application.
I have. Except that the only thing that hinted towards a LAN party was that I brought a laptop.
We were supposed to have some kind of a LAN party (mostly for-fun coding) with a few friends at their place. When I came to their shared apartment, it turned out that there were actually a few more people than I expected (including babes, if you want to put it that way), and the rest weren't there for a LAN but perhaps for a party. It just happened that some rare guests were around the same evening.
I never woke my laptop from suspend. So, yes in a LAN party, but not really.
In some situations saying "we" instead of "me", and especially instead of "you", actually makes sense. Especially when addressing problems you don't want to personify them too much. That will only lead to people taking the comments, well, personally, and your goal is to improve things, not to make someone feel insecure.
Saying "we" may also improve the feeling of working on a common challenge, although that may work better when talking with peers or those you manage rather than your superior.
I'd guess making customized systems involves a lot of design work etc. as well, and I'm not sure if GP included all those people in the 10% figure of production workers.
In fact, the way I understood the post was that the low figure of people involved in physically making the devices was exactly because of the low volume whereas the individual customizations and other design works requires a lot of people who aren't physically making the devices but would still be essential for the business.
I guess it boils down to what you consider a production job.
The whole source of this problem is that most programmers can't design (or follow UI guidelines)
Not to mention that UI design guidelines -- or any design guidelines for that matter -- don't work all that well if you just try to follow them brainlessly without understanding the rationale behind them. Almost any non-trivial design guideline touches on things that are complex enough not to really be covered by the guidelines alone, and blindly following them can even cause the "designer" to work against the very reasons why the guideline has been enacted.
Guidelines are obviously good to have because they can help avoid the common pitfalls and also because they promote consistency, but they alone aren't nearly enough for a good or even decent UI design. Neither are processes.
My point was that there's still price pressure, even on Microsoft. The original grandparent of my post gave, perhaps unintentionally, the idea that a subscription model would give MS the opportunity to rise their prices from high to really high (which something approaching $100 per *month* for the basic software of one workstation would, IMHO, be). That isn't necessarily the case.
Other than that, I'd mod your reply up if that were possible.
Did you read the context? The e-mail client (maybe I should have said Outlook clone) was an example based on the GPP of my post. If the e-mail client as an example disturbs you, substitute it with anything else from his list of examples, and adjust numbers accordingly.
And even if you decided to still use the MS base OS, what would prevent third parties from providing software or services to compete with Microsoft's? $10 for an e-mail client would be quite steep -- why not produce a competing service? If a license for a single utility used to cost, say, $20, and you expect your customers to stay at least for a few months, make it $3 a month or whatever seems feasible. It might well be less than $10 anyway, so you'd be outpricing MS.
But then, I wouldn't imagine MS would push the prices that high, for the very reason that few people would be paying that much if there are alternatives. So no, it wouldn't be $90 per month per customer.
Well, I don't know about the other ones, but Erowid isn't generally known as a drug scare site. Rather, it has material from several sources. In any case, it definitely doesn't count as an anti-psychoactives propaganda site.
If I were a kperson, I might be offended by your simplistic views. You see, the kpeople are way too inventive to just stick with kprefixes. Here's a fixed version for you:
A kbit klike kthe kpeople kthen sinke kthey kdo kthis kfar ktoo koften. mukh kmore koften kthan kthe kGNOME kpeople
They seem to primarily provide a low-level library that higher-level toolkits could be built upon, so I'm not completely sure how big a point they would make about providing screenshots. Of course that might be good for marketing -- something that many free software projects could learn a thing or two about -- but says nothing whatsoever about the technical quality of a low-level library. How many screenshots of the Linux kernel can you find on kernel.org?
Funny, I could say exactly the same about Linux (or at least a widely used distro), except perhaps for "the most wild assed software", depending on what that means.
Slashdot Mirror
Seems to work on bash, and checkbashisms doesn't complain about that either (it complains about $RANDOM, though).
No, I didn't try it with the "rm -rf /" part.
I've seen real cases where removing malware has been rather difficult when said malware is already running. Of course those systems actually did have real-time protection, so those times it didn't help. I'd still argue that if you want to fight malware once it's already managed to get itself running on the system, you're fighting a difficult battle -- the malware can interfere with the protection.
I'm not a Mac user but AFAIK Spotlight (as well as other desktop search systems) build and maintain an index of file contents, not only of the file name (as locate does).
Grep of course searches by file contents but the search can take a long time whereas an index would allow the search to be done in a matter of seconds or so. Another thing is that desktop search engines tend to support parsing and indexing the text from many common file types, also binary ones. With grep you may not be as lucky, depending on the file format.
Of course all parts of the desktop search have existed for a long time. It's just a matter of who puts things together, as it so often is.
Don't worry -- it's not 2072 yet.
Putting the gear to neutral or leaving the clutch in may have been a good idea 20 years ago, but nowadays with modern engines the key to saving fuel is actually not doing that.
Now, I'm no expert, but AFAIK with old-style carburetor engines the fuel consumption would be directly affected by the engine RPM. Clearly you could get the RPM quite low by having the engine idle instead of engine braking.
With modern injection engines the fuel flow is controlled by an electronic control unit, and fuel consumption is largely proportional to how much you push the gas pedal. The unit can actually stop the fuel flow completely when the gas pedal is not being pressed (so clearly no acceleration is desired) and the gear is in and the clutch is connected because the movement of the cars (and wheels) keeps the engine moving anyway. Fuel flow and ignition is resumed when needed.
If you disconnect the engine from the wheels by shifting to neutral or leaving the clutch in, you're forcing the control unit to keep feeding fuel into the engine because in that case the engine has to keep idling by its own power.
Wikipedia says:
In cars with a manual transmission, fuel can be saved while the car is coasting in gear. This is because the car's movement is keeping the engine rotating, so there is no need to use fuel for this purpose. Control units on modern transmissions recognize this and stop all fuel flow to the engine when possible. (Automatic transmission cars rely on torque converters, not clutches, to transmit power from the engine to the gearbox, and whereas clutches can transmit power in both directions, torque converters, especially when tuned as they are in cars, are not good at transmitting power in the opposite direction.)
If it's so trivial that any application run under RunAs behaves exactly as if run after logging in interactively as the same user, why do you have to "understand how the system works"?
I really don't know how RunAs works, but if you think about sudo on unix, it's not quite as simple as that. If you've originally logged in as "foo" and then run a command as user "bar" through sudo, does the application you run get the environment (environment variables such as locale settings, home directory location, etc.) from foo or from bar? Or a part from one and another part from the other.
Of course you can make it behave they way that is appropriate for the situation. Perhaps it's the same with RunAs and what you mean by "not understanding" it is exactly that. But "zero difference" between RunAs and an interactive user session may still not quite hold due to such details, and the existence of a magical flag to for applications to detect RunAs is likewise irrelevant.
There's no reason why you couldn't have Python 2.5, 2.6 and 3.0 installed on the same system. You can even supply your own Python environment with your software package if you really want to.
I don't know about Windows, but on *nix you can also specify which interpreter to use at the beginning of the script, and the different versions of the Python interpreter will be available under different names so you can differentiate. For example the default Python version on my system is 2.5, also available as "python2.5". Looks like I still have also 2.4 installed and available as "python2.4".
So, if your code requires Python 2.5, you could just have "#!/usr/bin/env python2.5" at the beginning of your script, and it would be run using the python2.5 command.
If you decide to write for 3.0, of course you'll have to specify 3.0 as a requirement. That happens with any new major versions of pretty much anything. If you take advantage of new features in Java 1.6, obviously you can't deploy it on Java 1.5.
You'll need to have your end-users install Python 3.0 (unless you provide it yourself), but that doesn't mean they couldn't keep also using 2.x for whatever other needs they may have.
I will say the same thing that plagues python has plagued Java and probably hosts of other platforms.
Java? Some things have been broken occasionally in newer releases if you're doing stuff that's exotic enough, but in general I'd say that Java has been pretty damn backwards-compatible all the way. Save for those odd bugs, things written and compiled for Java 1.3 tend to run pretty niftily on 1.6.
Very true. Good point. I didn't come to think that they'd want to allow impossible paths, but then, why not...
Their method is to automagically profile the software when it's compiled. That's obviously something antivirus software doesn't do.
Antivirus software generally doesn't know how a particular piece of legitimate software is supposed to behave. The idea here is that the approach these guys are taking is exactly to try to build a profile for the normal behaviour of the application (or some parts of it, namely the pattern of syscalls). The analysis would be done at compile time, and when the application is being run its pattern of making syscalls would be matched against the known profile. That way the system could supposedly notice a compromised application or service because its pattern would be different than expected.
Also, the method would be powerless against trojans, for example, because they don't work by exploiting vulnerabilities in legitimate software and changing the way it's executed. To me the suggested system seems more like just a potentially boosted intrusion detection system, not general malware-pattern detection, which is what antivirus software does.
How well their profiling would actually work, that I don't know. Theoretically you can't make a complete analysis of all paths the execution of a program could possibly take (for an arbitrary program anyway). Multithreading and inter-process communication might make that even more difficult. But then, maybe it would be just possible to do it for some cases that practically occur with some decent probability.
These guys make a point of avoiding the labour involved in manually building the profile. (FWIW, I don't know about anything service profiling in Vista -- in fact, I had never heard about it -- but your description also sounds somewhat reminiscent of AppArmor.)
The problem is that if there aren't enough people eating the cooked meal, doing so might become rather expensive due to lack of supply or choice.
There's at least one reason why having some share in the market is good also for those who don't require the hand-holding: in the world with commercial interests, there's a lot more support for systems with at least some market share, and that support is often necessary to have a reasonable level of compatibility. Not everything is under the control of the free software community, and that is particularly true if we lack market share.
Is it possible to find hardware that works even with niche operating systems? Yes. Is it a good thing for me if I have fewer choices doing that, potentially forcing me to take a technically inferior or more expensive product just to satisfy the compatibility requirements? No.
The same goes for software: The free software community may be able to cater to most of the needs of its members, also mine. However, there are always situations where I may not have much choice.
Let's say that my company uses a proprietary VoIP solution for some internal communication. I can use Linux for my development work, but if that proprietary application didn't work on my Linux system, I'd be forced to use Windows just because of that. Changing the application to something less proprietary may not be within my power. Using two different operating systems on a daily basis would not be very convenient. While I'd probably end up doing just that, it would also be possible that I or someone else would have to give up using free software due to lack of support from vendors whose products they need to use anyway.
The same goes for other proprietary formats and codecs, although the community has been surprisingly good at supporting many of those (more or less legally) with free implementations. Nevertheless, when most other people use proprietary systems, commercial interests dictate that life is easier also for many of us who wouldn't need the hand-holding itself when there's some degree of commercial interest in the system we use.
Of course there may be valid concern that if we give up too much to accommodate those commercial interests, we lose exactly what we're trying to achieve. I want a (more or less) free system that I can more or less conveniently use, but of course if I give up significant freedom to achieve the usability, I fail to satisfy the other desire I have.
I tend to follow the idea that a 99% free system that is usable for, say, 10% (or 50% or whatever) of people provides more freedom than a 100% free system that is only usable for 1% of people. Where you go over the line of giving up too much freedom is obviously debatable. For me, the current (or former?) state of Ubuntu where they provide proprietary drivers where needed and partially support some proprietary applications is acceptable. That includes the former policy of providing a semi-nonfree Firefox (with the branding making it that way) but without a click-through EULA.
It's very sad that Mozilla has chosen to do this. It's as if they don't consider the distributors their collaborators anymore. However, if I were facing this situation as Canonical, I might have made the same choice even if it wouldn't be easy. Brands are a big thing no matter how much I dislike that, and I can easily see how a newly introduced Ubuntu user will, as his first thing, wonder he can get Firefox if he doesn't find it on his default setup.
Actually, some existing software still does something pretty close to this. In Evince, for example, you can always scroll exactly to the next page regardless of how much of a page is being displayed at the current zoom level by pressing Ctrl+PgDn (and similarly for up). Adobe Reader might behave the same way but I'm not sure. I think OpenOffice.org Impress (the powerpointy thingy) also does that.
I didn't read the patent application, but if TFA has any clue, the only difference between that and the MS 'invention' is that in the latter one the viewer would scroll exactly to the same position in the next/previous page as you were previously viewing on the original page. For example, if you're 1/4 down page n, MS PageDown 2008 (TM) would get you to the position 1/4 down page n+1. The examples I mentioned earlier always give you the beginning of the next/previous page.
Nevertheless, seems trivial. But then, again, I didn't read the patent application.
I have. Except that the only thing that hinted towards a LAN party was that I brought a laptop.
We were supposed to have some kind of a LAN party (mostly for-fun coding) with a few friends at their place. When I came to their shared apartment, it turned out that there were actually a few more people than I expected (including babes, if you want to put it that way), and the rest weren't there for a LAN but perhaps for a party. It just happened that some rare guests were around the same evening.
I never woke my laptop from suspend. So, yes in a LAN party, but not really.
In some situations saying "we" instead of "me", and especially instead of "you", actually makes sense. Especially when addressing problems you don't want to personify them too much. That will only lead to people taking the comments, well, personally, and your goal is to improve things, not to make someone feel insecure.
Saying "we" may also improve the feeling of working on a common challenge, although that may work better when talking with peers or those you manage rather than your superior.
I'd guess making customized systems involves a lot of design work etc. as well, and I'm not sure if GP included all those people in the 10% figure of production workers.
In fact, the way I understood the post was that the low figure of people involved in physically making the devices was exactly because of the low volume whereas the individual customizations and other design works requires a lot of people who aren't physically making the devices but would still be essential for the business.
I guess it boils down to what you consider a production job.
Even if they can tell that the food is bad, that doesn't necessarily mean they know why it's bad or how to make it better.
The whole source of this problem is that most programmers can't design (or follow UI guidelines)
Not to mention that UI design guidelines -- or any design guidelines for that matter -- don't work all that well if you just try to follow them brainlessly without understanding the rationale behind them. Almost any non-trivial design guideline touches on things that are complex enough not to really be covered by the guidelines alone, and blindly following them can even cause the "designer" to work against the very reasons why the guideline has been enacted.
Guidelines are obviously good to have because they can help avoid the common pitfalls and also because they promote consistency, but they alone aren't nearly enough for a good or even decent UI design. Neither are processes.
My point was that there's still price pressure, even on Microsoft. The original grandparent of my post gave, perhaps unintentionally, the idea that a subscription model would give MS the opportunity to rise their prices from high to really high (which something approaching $100 per *month* for the basic software of one workstation would, IMHO, be). That isn't necessarily the case.
Other than that, I'd mod your reply up if that were possible.
Did you read the context? The e-mail client (maybe I should have said Outlook clone) was an example based on the GPP of my post. If the e-mail client as an example disturbs you, substitute it with anything else from his list of examples, and adjust numbers accordingly.
And even if you decided to still use the MS base OS, what would prevent third parties from providing software or services to compete with Microsoft's? $10 for an e-mail client would be quite steep -- why not produce a competing service? If a license for a single utility used to cost, say, $20, and you expect your customers to stay at least for a few months, make it $3 a month or whatever seems feasible. It might well be less than $10 anyway, so you'd be outpricing MS.
But then, I wouldn't imagine MS would push the prices that high, for the very reason that few people would be paying that much if there are alternatives. So no, it wouldn't be $90 per month per customer.
Well, I don't know about the other ones, but Erowid isn't generally known as a drug scare site. Rather, it has material from several sources. In any case, it definitely doesn't count as an anti-psychoactives propaganda site.
A kbit klike kthe kpeople kthen sinke kthey kdo kthis kfar ktoo koften. mukh kmore koften kthan kthe kGNOME kpeople
They seem to primarily provide a low-level library that higher-level toolkits could be built upon, so I'm not completely sure how big a point they would make about providing screenshots. Of course that might be good for marketing -- something that many free software projects could learn a thing or two about -- but says nothing whatsoever about the technical quality of a low-level library. How many screenshots of the Linux kernel can you find on kernel.org?
Funny, I could say exactly the same about Linux (or at least a widely used distro), except perhaps for "the most wild assed software", depending on what that means.