> They say it has a WINE implementation, but they don't call it "WINE-based".
Right. It's an operating system, including a kernel, init system, etc. About 9 million lines of code in total.
Wine is a library which provides some of the API functions which are exposed to userland. Wine is about 2.8 million lines of code. Not that Wine is much smaller than operating system it runs on. ReactOS uses the Wine for many functions, Windows Vista uses the IE library for many functions. ReactOS isn't Wine-based any more than Windows is IE-based.
> And what's the point of including a variation of Python 1.7
You mean 2.7. Python is useful for scripting all sorts of things. As you may have noticed, Microsoft comes out with a completely new scripting environment every few years; apparently they don't think they got it right and they ned to start over from scratch. Some people agree, and Python is a very reasonable way to script things.
> And why only a read-only NTFS implementation?
Because safely writing to NTFS is hard. The damn thing was designed by/Microsoft/. Until the code for writing is safe (as safe as NTFS can be), read-only is better than nothing, and much safer than a buggy read-write implementation.
> But I can't really see why you would want to use it compared to (say) Ubuntu or CentOS which are very polished and usable these days.
Later, if and when ReactOS is more mature, several use cases make sense. Right now, the primary use case I can think of is if your business, or something important to you, depends on a complex Windows application which can't reasonably be re-written. Perhaps you don't want to use Windows for a million reasons, especially an old version of Windows.
The article says that the design / print software is based on an open software package and it works with other 3D printers.
If the software uses standard protocols to talk to printers, that suggests that printer accepts the standard protocol and can therefore be controlled by other software.
People do build there own, and there are about a jillion web sites with more information, including detailed plans in some cases.
A main reason it's not cheaper is that tolerances add up. If you have.05" of slop in your screw drive, and 0.05" in your motors, and 0.05 in your bearings, and 0.05 sideways slop in your Z axis, that means each layer may be 0.2 inches off from the last - almost a quarter inch. That's totally unusable. To get 0.001" or better on all your moving parts means you'll be buying some very specific parts, and probably spending some money.
Now suppose you could spend 8 hours building and adjusting it, and save $250. That's $30 / hour. If you're skilled, you can probably make more than $30 / hour at your job, so you're better off working those hours and buying one.
As I said, building one is certainly feasible. It's neither cheap nor quick, and the manufactured ones have more of the glitches worked out.
What we may see more of is people buying cheap ones and making their own improvements, like polishing certain parts with a Dremel, adding springs to take up slack, etc.
After a few more minutes of research I see what I wrote the China Syndrome part the way I did. I DID see that the percentage of Americans opposed to nuclear power tripled in the month after China Syndrome was released. I didn't include that fact because I read it in a biased source and I needed to find a reliable source.
It turns out that IS true. The major opposition to nuclear power really started in earnest right after China Syndrome was released in theaters. However, also 12 days after the movie was released, the Three Mile Island scare happened. So you can't legitimately say the movie caused the poll numbers to change - Three Mile Island happened at the same time.
Thanks for those ideas, and for reading it. I'll cross-reference your comments and probably make some changes.
I think I came across evidence that public opposition to nuclear power did in fact jump dramatically (as in triple or quadruple) upon the release of China Syndrome (as measured via polls). I'll check that. Based on what I remember, the anti-nuclear power movement is in fact borne of that fictional movie. That does shed some light on the underlying fear and whether it's based on credible facts, or indeed it's based on a work of fiction. I'll see if I can find the numbers and reword or remove that part.
> What is the target audience of this review paper?
The grader for my sophomore English class.:) And the occasional Slashdot reader. After founding and running IT companies for 20 years, I went back to finish college a couple of years ago. School is a piece of cake now; I had some test questions about open source software that I wrote, and IETF standards that I helped develop. School is easy when the names of historical figures you havw to memorize are people you've worked with. I'm definitely going to get my masters next.
if you ignore the slippery slope and pretend there are no gray areas, almost everyone would probably that correcting clear defects is okay.
It's that fuzzy line, the gray area, that's the whole problem. Where to draw the line, who decides where to draw the line, and who enforces the line?
Consider what's happened with plastic surgery. Plastic surgery for the repair of facial injuries dates back about 5,000 years, to ancient Egypt. For thousands of years, these techniques were mostly* (though not entirely) limited to "correcting defects", mostly due to injury. Gradually, people said that slightly uneven breasts were a "defect" that should be corrected, then a nose that's larger than average needs to be "fixed". We know what's happened with that over the last 50 years.
Most people would probably say that would be wrong to subject a child (who cannot give informed consent) to surgical risk, a painful recovery etc, because the parents prefer the kid's nose to be rounder. The same slope exists here - is it okay to subject a person to the risk of severe genetic deformity caused by messing with their genes, based on a parent thinking that the kid's curly hair needs to be "fixed", to be straight rather than curly? it would seem that's not okay, but where to draw the line? Who draws the line?
How does it happen that two people independently notice a bug? They both run the program, and it crashes because there's a bug. They're both running the same code, so they get the same crash. It's not immediately obvious that the crash has any security impact, and if so, how severe.
In the case of Red Hat and Google, both have teams who fix bugs in Linux, so whoever notices it files a bug report for the appropriate team. At Red Hat, when it's noticed that there are potential security implications, it's sent to Florian's team. Florian's team works carefully to fully understand it, look for related issues*, and work out the BEST way to fix it. They have a pile of bugs they're working at any given time.
Over at Google, the bug was found later, but the severity of the security implications were noticed sooner, so Google found the security issue WHILE Red Hat was working through their process.
* An example of Red Hat's "find and fix the whole issue, not just the obvious part", is shell shock. After the initial CVE for shell shock, several people proposed different ways of fixing it. Florian was one, he quickly worked on it and released a proposed patch. Over the next few days there were three MORE CVEs for shell shock, covering different variations on the same theme. Florian's initial patch covered all of them, including the ones that hadn't been fully characterized when he proposed it. His approach was approved by general consensus and that's what we all use today - partly because he put in the time and effort to fix the broader issue, not just the specific case that had been identified. This approach means that sometimes it takes Red Hat a while to release a fix, but when they do, it's the right fix.
Exactly. Unique local addresses in IPv6 are not globally routable, just like private addresses in IPv4. They can be used just like IPv4 private addresses, if you want to. Unique local is all addressed starting with FD:.
The IPv6 version is better, though, because each local network is likely to use different IPs, so you can choose to locally route them. Here are a couple of examples of why that's good. Suppose you have a small office in College Station, where someone set up a typical SOHO network with unique local addresses. Also, your headquarters office in Dallas has it's network with unique local. Just like IPv4, on the internet can't reach either network. Unlike IPv4, the two offices probably use -different- IP addresses, and you can decide to have your VPN router route between them, forming a company-wide network.
Similarly, suppose that ABC LLC buys XYZ Corp. With IPv4, integrating the networks in a pain - both companies probably have machines with the same IP addresses, so you have to change the IPs on all of equipment used by XYZ. With IPv6, they are unlikely to match, so you can easily merge the two networks by routing between the two sets of "private" IPs (unique local IPs).
You make a good point about the a priori probabilities. If most customers are legit, then most customers who are flagged may be legit. ("97% accuracy " doesn't tell us if there are 3% false positives or 3% false negatives. There's a BIG difference. )
However 97% from a single indicator is very useful because indicators can be combined. Consider you're looking at someone and classifying them as male or female. One thing you see is the length of their hair. You also see what kind of shirt their wearing, etc. Each of these indicators is only 90% accurate, but together they allow you to recognize male vs female correctly 99.5% of the time, and you know whem you're unsure.
Applying this to the current question, if their browser is set to prefer Russian, their latency and jitter is characteristic of Russia, their form of payment is typical of Russian vpn users, they're watching movies popular in Russia, etc, they might be in Russia or a neighboring country. Again, you can tell when you're getting conflicting indicators or borderline values, so you can compute the level of uncertainty.
If they had PROPER backups, simply restoring would restore them to the same vulnerable state they were in just before the attack, and the attackers would immediately re-infect. Before restoring, they have to protect the system from being exploited again. They should try to determine how the original attack was carried out and fix that hole. Also, a too-strict intrusion prevention system at the firewall would be a good idea. They can whitelist as required.
That assumes PROPER backups, but most people don't use a proper backup strategy. Most fail one of the following points:
Tested regularly. VERY often, I see that customers backup stopped working months ago and they didn't know it.
Rolling/ incremental. A backup from last night does you no good if ransomware encrypted everything yesterday afternoon. You need to be able to retrieve backups from multiple points in time.
Off site. Fire, burglary, lightning, 3rd party data center problems - all of these cause loss of racks of equipment. If your backup is sitting next to your live server, you've lost both.
Restorable quickly, and fully (bootable from bare metal). Some tape backups take DAYS to restore a single large server, as do some cloud backups.
These are all lessons learned and confirmed from actual experience assisting real customers. I designed the Clonebox system based on these lessons.
> I'm kind of big on letting people make their own choices. I'm okay with people making choices that I'd not personally make. You're usually pretty smart, what am I missing here?
Given that's in response to my post "The point is that nobody wants to use crap devices", I'd say we're more or less on the same page. I said nobody wants it; I didn't say it should be illegal.
The above statement does of course have an exception- when Clinton was Commander in Chief, anyone could of course attack US naval vessels at will. The response each time - not even a strongly worded email. Never before or since has the US Navy been a target one could attack without swift and sure consequences.
In short, no. The vessel is still the property of the owner, as is all flotsam and jetsom.
A salvor IS entitled to reasonable compensation of the property is in "real peril". Reasonable is determined by imagining if the owner of the vessel and the salvor had time and opportunity to pre-negotiate a price for salvaging the vessel. The amount owed is roughly what they would have negotiated ahead of time, if they had the opportunity to do so, for rescuing the property. (Rescuing any people on board is separate law.)
Additionally, history suggests it is unwise to mess with a vessel of the US Navy.:)
The point is that nobody wants to use crap devices. Android devices are cheap, and few people want to get online with something cheaper. Both Firefox OS and Free Basics were stupid _business ventures_ because nobody wants to be a customer of them.
The fact that Free Basics ALSO limited which sites you could access is another problem with that idea.
Fyi, inexpensive fire safes are rated to protect PAPER from burning for 10-15 minutes. They'll protect most computer media for about 7 minutes. The average home fire lasts about 30 minutes. Therefore, an inexpensive fire safe is "security theatre " for data - if you get the false impression that you're protected, that's a net negative.
They also don't protect from burglary in most cases.
> This is why local storage will always be king. I can be certain that nothing is going to happen to my stuff.
I take it you test your offsite backups regularly? Of course if you don't, you can be certain that eventually something will happen to your local storage and you'll lose your data - fire, theft, whatever.
I'm maybe 25% of the way down the page and already I've seen three posts from you about "wireless ethernet". Since you feel the need to keep posting that in reply to every message , I'll let you know: wireless Ethernet does not exist. No such thing. Unless it's installed in a Ford Chevy, by a man woman, during winter summer.
Perhaps the reason the people who make the standards have an opinion different from yours is because they have some clue what they're talking about.
> However, a better solution would be to consult the --help text or manual page and remove the uncertainty.
While carefully reading the man page again for each command you type and carefully comparing what you're typing for each option to it's manual page specification -would- be effective, I'm not sure how many people want to spend the time doing that. Tapping the space bar by habit is a MUCH quicker way to avoid the common error case.
Much like consistently putting switches before arguments: command file1 file 2 -a -b -- Sometimes works as expected, common source of error. command -a -b file1 file 2 -- Consistently works as expected, rarely / never causes error.
It doesn't take any longer to type the options before the arguments, and it works with POSIX-correct software.
Where did Boeing, or anyone, claim 100% efficiency? A system like this might manage 30% efficiency.
That's why solar-electric is a nice supplemental energy source for the sunny hours on sunny days - there's no practical way to store city-scale amounts of power. You always waste 70%-80% of it and/or require hundreds of square miles of land or something else ridiculous.
Avoiding inconsistent behavior due to optional arguments is the whole point. Reread what I just said:
-AB DOES set B as the argument to -A, if -A can take an argument. -AB is two arguments IF -A can't take an argument. So on Linux, -AB can have two different meanings.
It's easy to forget that -A CAN optionally take an argument, if you're accustomed to using it without. You wouldn't forget that -o always has a required argument, if you use it at all. That is, you'd never use "ls -I ht" expecting it to behave the same as "ls ht -I", because obviously -I needs argument.
Slashdot Mirror
> $ perl -pni.bak -e 's/Bin Laden/ISIS/sgi'
Nah, these are morons we're dealing with. They did ctrl-f, not Perl.
Otherwise, spot-on.
> They say it has a WINE implementation, but they don't call it "WINE-based".
Right. It's an operating system, including a kernel, init system, etc. About 9 million lines of code in total.
Wine is a library which provides some of the API functions which are exposed to userland. Wine is about 2.8 million lines of code. Not that Wine is much smaller than operating system it runs on. ReactOS uses the Wine for many functions, Windows Vista uses the IE library for many functions. ReactOS isn't Wine-based any more than Windows is IE-based.
> And what's the point of including a variation of Python 1.7
You mean 2.7. Python is useful for scripting all sorts of things. As you may have noticed, Microsoft comes out with a completely new scripting environment every few years; apparently they don't think they got it right and they ned to start over from scratch. Some people agree, and Python is a very reasonable way to script things.
> And why only a read-only NTFS implementation?
Because safely writing to NTFS is hard. The damn thing was designed by /Microsoft/. Until the code for writing is safe (as safe as NTFS can be), read-only is better than nothing, and much safer than a buggy read-write implementation.
> But I can't really see why you would want to use it compared to (say) Ubuntu or CentOS which are very polished and usable these days.
Later, if and when ReactOS is more mature, several use cases make sense. Right now, the primary use case I can think of is if your business, or something important to you, depends on a complex Windows application which can't reasonably be re-written. Perhaps you don't want to use Windows for a million reasons, especially an old version of Windows.
The article says that the design / print software is based on an open software package and it works with other 3D printers.
If the software uses standard protocols to talk to printers, that suggests that printer accepts the standard protocol and can therefore be controlled by other software.
People do build there own, and there are about a jillion web sites with more information, including detailed plans in some cases.
A main reason it's not cheaper is that tolerances add up. If you have .05" of slop in your screw drive, and 0.05" in your motors, and 0.05 in your bearings, and 0.05 sideways slop in your Z axis, that means each layer may be 0.2 inches off from the last - almost a quarter inch. That's totally unusable. To get 0.001" or better on all your moving parts means you'll be buying some very specific parts, and probably spending some money.
Now suppose you could spend 8 hours building and adjusting it, and save $250. That's $30 / hour. If you're skilled, you can probably make more than $30 / hour at your job, so you're better off working those hours and buying one.
As I said, building one is certainly feasible. It's neither cheap nor quick, and the manufactured ones have more of the glitches worked out.
What we may see more of is people buying cheap ones and making their own improvements, like polishing certain parts with a Dremel, adding springs to take up slack, etc.
After a few more minutes of research I see what I wrote the China Syndrome part the way I did. I DID see that the percentage of Americans opposed to nuclear power tripled in the month after China Syndrome was released. I didn't include that fact because I read it in a biased source and I needed to find a reliable source.
It turns out that IS true. The major opposition to nuclear power really started in earnest right after China Syndrome was released in theaters. However, also 12 days after the movie was released, the Three Mile Island scare happened. So you can't legitimately say the movie caused the poll numbers to change - Three Mile Island happened at the same time.
I'm glad I didn't include cite that source.
Thanks for those ideas, and for reading it. I'll cross-reference your comments and probably make some changes.
I think I came across evidence that public opposition to nuclear power did in fact jump dramatically (as in triple or quadruple) upon the release of China Syndrome (as measured via polls). I'll check that. Based on what I remember, the anti-nuclear power movement is in fact borne of that fictional movie. That does shed some light on the underlying fear and whether it's based on credible facts, or indeed it's based on a work of fiction. I'll see if I can find the numbers and reword or remove that part.
> What is the target audience of this review paper?
The grader for my sophomore English class. :) And the occasional Slashdot reader. After founding and running IT companies for 20 years, I went back to finish college a couple of years ago. School is a piece of cake now; I had some test questions about open source software that I wrote, and IETF standards that I helped develop. School is easy when the names of historical figures you havw to memorize are people you've worked with. I'm definitely going to get my masters next.
if you ignore the slippery slope and pretend there are no gray areas, almost everyone would probably that correcting clear defects is okay.
It's that fuzzy line, the gray area, that's the whole problem. Where to draw the line, who decides where to draw the line, and who enforces the line?
Consider what's happened with plastic surgery. Plastic surgery for the repair of facial injuries dates back about 5,000 years, to ancient Egypt. For thousands of years, these techniques were mostly* (though not entirely) limited to "correcting defects", mostly due to injury. Gradually, people said that slightly uneven breasts were a "defect" that should be corrected, then a nose that's larger than average needs to be "fixed". We know what's happened with that over the last 50 years.
Most people would probably say that would be wrong to subject a child (who cannot give informed consent) to surgical risk, a painful recovery etc, because the parents prefer the kid's nose to be rounder. The same slope exists here - is it okay to subject a person to the risk of severe genetic deformity caused by messing with their genes, based on a parent thinking that the kid's curly hair needs to be "fixed", to be straight rather than curly? it would seem that's not okay, but where to draw the line? Who draws the line?
How does it happen that two people independently notice a bug? They both run the program, and it crashes because there's a bug. They're both running the same code, so they get the same crash. It's not immediately obvious that the crash has any security impact, and if so, how severe.
In the case of Red Hat and Google, both have teams who fix bugs in Linux, so whoever notices it files a bug report for the appropriate team. At Red Hat, when it's noticed that there are potential security implications, it's sent to Florian's team. Florian's team works carefully to fully understand it, look for related issues*, and work out the BEST way to fix it. They have a pile of bugs they're working at any given time.
Over at Google, the bug was found later, but the severity of the security implications were noticed sooner, so Google found the security issue WHILE Red Hat was working through their process.
* An example of Red Hat's "find and fix the whole issue, not just the obvious part", is shell shock. After the initial CVE for shell shock, several people proposed different ways of fixing it. Florian was one, he quickly worked on it and released a proposed patch. Over the next few days there were three MORE CVEs for shell shock, covering different variations on the same theme. Florian's initial patch covered all of them, including the ones that hadn't been fully characterized when he proposed it. His approach was approved by general consensus and that's what we all use today - partly because he put in the time and effort to fix the broader issue, not just the specific case that had been identified. This approach means that sometimes it takes Red Hat a while to release a fix, but when they do, it's the right fix.
Exactly. Unique local addresses in IPv6 are not globally routable, just like private addresses in IPv4. They can be used just like IPv4 private addresses, if you want to. Unique local is all addressed starting with FD:.
The IPv6 version is better, though, because each local network is likely to use different IPs, so you can choose to locally route them. Here are a couple of examples of why that's good. Suppose you have a small office in College Station, where someone set up a typical SOHO network with unique local addresses. Also, your headquarters office in Dallas has it's network with unique local. Just like IPv4, on the internet can't reach either network. Unlike IPv4, the two offices probably use -different- IP addresses, and you can decide to have your VPN router route between them, forming a company-wide network.
Similarly, suppose that ABC LLC buys XYZ Corp. With IPv4, integrating the networks in a pain - both companies probably have machines with the same IP addresses, so you have to change the IPs on all of equipment used by XYZ. With IPv6, they are unlikely to match, so you can easily merge the two networks by routing between the two sets of "private" IPs (unique local IPs).
You make a good point about the a priori probabilities. If most customers are legit, then most customers who are flagged may be legit. ("97% accuracy " doesn't tell us if there are 3% false positives or 3% false negatives. There's a BIG difference. )
However 97% from a single indicator is very useful because indicators can be combined. Consider you're looking at someone and classifying them as male or female. One thing you see is the length of their hair. You also see what kind of shirt their wearing, etc. Each of these indicators is only 90% accurate, but together they allow you to recognize male vs female correctly 99.5% of the time, and you know whem you're unsure.
Applying this to the current question, if their browser is set to prefer Russian, their latency and jitter is characteristic of Russia, their form of payment is typical of Russian vpn users, they're watching movies popular in Russia, etc, they might be in Russia or a neighboring country. Again, you can tell when you're getting conflicting indicators or borderline values, so you can compute the level of uncertainty.
If they had PROPER backups, simply restoring would restore them to the same vulnerable state they were in just before the attack, and the attackers would immediately re-infect. Before restoring, they have to protect the system from being exploited again. They should try to determine how the original attack was carried out and fix that hole. Also, a too-strict intrusion prevention system at the firewall would be a good idea. They can whitelist as required.
That assumes PROPER backups, but most people don't use a proper backup strategy. Most fail one of the following points:
Tested regularly. VERY often, I see that customers backup stopped working months ago and they didn't know it.
Rolling/ incremental. A backup from last night does you no good if ransomware encrypted everything yesterday afternoon. You need to be able to retrieve backups from multiple points in time.
Off site. Fire, burglary, lightning, 3rd party data center problems - all of these cause loss of racks of equipment. If your backup is sitting next to your live server, you've lost both.
Restorable quickly, and fully (bootable from bare metal). Some tape backups take DAYS to restore a single large server, as do some cloud backups.
These are all lessons learned and confirmed from actual experience assisting real customers. I designed the Clonebox system based on these lessons.
> I'm kind of big on letting people make their own choices. I'm okay with people making choices that I'd not personally make. You're usually pretty smart, what am I missing here?
Given that's in response to my post "The point is that nobody wants to use crap devices", I'd say we're more or less on the same page. I said nobody wants it; I didn't say it should be illegal.
The above statement does of course have an exception- when Clinton was Commander in Chief, anyone could of course attack US naval vessels at will. The response each time - not even a strongly worded email. Never before or since has the US Navy been a target one could attack without swift and sure consequences.
> One of its stated purposes is countering mines, which I'd think would require some sort of weaponry.
Any ship can be a minesweeper - once.
People have tried messing with the US Navy before. It has never worked out well.
In short, no. The vessel is still the property of the owner, as is all flotsam and jetsom.
A salvor IS entitled to reasonable compensation of the property is in "real peril". Reasonable is determined by imagining if the owner of the vessel and the salvor had time and opportunity to pre-negotiate a price for salvaging the vessel. The amount owed is roughly what they would have negotiated ahead of time, if they had the opportunity to do so, for rescuing the property. (Rescuing any people on board is separate law.)
Additionally, history suggests it is unwise to mess with a vessel of the US Navy. :)
The point is that nobody wants to use crap devices. Android devices are cheap, and few people want to get online with something cheaper. Both Firefox OS and Free Basics were stupid _business ventures_ because nobody wants to be a customer of them.
The fact that Free Basics ALSO limited which sites you could access is another problem with that idea.
Zuckerburg' s approach was in some ways similar to AOL, an approach that stopped being viable in the 1990s.
Fyi, inexpensive fire safes are rated to protect PAPER from burning for 10-15 minutes. They'll protect most computer media for about 7 minutes. The average home fire lasts about 30 minutes. Therefore, an inexpensive fire safe is "security theatre " for data - if you get the false impression that you're protected, that's a net negative.
They also don't protect from burglary in most cases.
> This is why local storage will always be king. I can be certain that nothing is going to happen to my stuff.
I take it you test your offsite backups regularly? Of course if you don't, you can be certain that eventually something will happen to your local storage and you'll lose your data - fire, theft, whatever.
I'm maybe 25% of the way down the page and already I've seen three posts from you about "wireless ethernet". Since you feel the need to keep posting that in reply to every message , I'll let you know: wireless Ethernet does not exist. No such thing. Unless it's installed in a Ford Chevy, by a man woman, during winter summer.
Perhaps the reason the people who make the standards have an opinion different from yours is because they have some clue what they're talking about.
> However, a better solution would be to consult the --help text or manual page and remove the uncertainty.
While carefully reading the man page again for each command you type and carefully comparing what you're typing for each option to it's manual page specification -would- be effective, I'm not sure how many people want to spend the time doing that. Tapping the space bar by habit is a MUCH quicker way to avoid the common error case.
Much like consistently putting switches before arguments:
command file1 file 2 -a -b -- Sometimes works as expected, common source of error.
command -a -b file1 file 2 -- Consistently works as expected, rarely / never causes error.
It doesn't take any longer to type the options before the arguments, and it works with POSIX-correct software.
Where did Boeing, or anyone, claim 100% efficiency? A system like this might manage 30% efficiency.
That's why solar-electric is a nice supplemental energy source for the sunny hours on sunny days - there's no practical way to store city-scale amounts of power. You always waste 70%-80% of it and/or require hundreds of square miles of land or something else ridiculous.
Avoiding inconsistent behavior due to optional arguments is the whole point. Reread what I just said:
-AB DOES set B as the argument to -A, if -A can take an argument. -AB is two arguments IF -A can't take an argument. So on Linux, -AB can have two different meanings.
It's easy to forget that -A CAN optionally take an argument, if you're accustomed to using it without. You wouldn't forget that -o always has a required argument, if you use it at all. That is, you'd never use "ls -I ht" expecting it to behave the same as "ls ht -I", because obviously -I needs argument.