Nice feature to have, but people have been using postgres (and other databases) sucessfully for years. How did they work around it?
You either move the blocking operation elsewhere (i.e., a trigger) or you don't. Data consistency is more important than performance (normally). The user can wait.
My only beef with PgSQL has been there since before the 7's. There is still no way to not show the list of databases to users who have no right or access to those databases. Because, unless you configure pg_hba.conf to forbid them from authenticating to that database, all users have the privilege to connect to any database they wish. They may not be able to do anything, but they can connect. IOW, what databases you can connect to are handled by the connection authentication mechanisms, and the GRANT system has no control over it. When you think about it, this really makes a ton of sense.
A sufficiently determined intruder or experienced wireless security guru will have no trouble sniffing valid MACs. Umm, no. Anyone who can sniff wireless frames gets to see the MAC addresses involved: they're part of every frame.
However, this precaution - more than anything - deters the less technologically savvy wardrivers/what-have-you that are causing most headaches. There is nothing conclusive out there to show this.
The problem with facile generalizations is that they generally aren't true -- pun intended. Wonderful, show this specific one isn't true.
Every time you add a layer of security, no matter how thin, you weed out another percentage of "mad leet haxors". Didn't you just say, 'The problem with facile generalizations is that they generally aren't true -- pun intended.'? An response consisting solely of logical fallicies doesn't merit much weight. You can't demonstrate this is true in all cases, so you fall victim to your first statement.
A determined professional can crack almost anything, but even "useless" measures like MAC filtering go a ways toward dissuading amateurs. That's just the thing, MAC filtering doesn't. The overwhelming majority of wireless adapters can change MAC addresses (hell, I have first-generation 802.11b consumer gear that can do it) and anyone with ability to run kimset or AirSnort and correctly interpret it's output can change a MAC address, especially in Windows. The gain is really zero, because it's such a trivial measure to defeat. Copy and paste. If the attacker can't manage that, one has to question their ability to successfully crack your wireless key and enter into their machine correctly in the first place.
Next time, try understanding a bit about the situation before posting that I might be wrong, simply because generalizations aren't always true.
I'm not even sure how shit like this gets posted. Editors need to learn to be fucking editors, and not bloggers.
The entire discussion of what's wrong with the IV usage under WEP is wrong. As is the "vulnerabilities" of CRC-32. It has no cryptographic purpose: it's intent is to ensure data integrity (i.e., not corrupted due to radio interference).
Anyone with any professional wireless experience knows that MAC filtering is a useless security measure, and shouldn't be bothered with.
There's more, but there's no real need to waste words on this tripe.
If they want to pretend to be IE, then that means they want to see messages that IE users see. You're missing the point. The point is: you shouldn't care what the user's browser is in the first place.
Why else would they set their user-agent to IE? Because of retarded sites that send broken pages to other UAs?
That's exactly why it's only a message telling users to switch, instead of blocking the whole site off from IE. The user who has no choice about what browser they use can just skip that message. YOu missed the point. The point is, you're essentially telling a portion of your userbase (perhaps a substantial one) that they're inferior due to a choice they have no control over.
They are >1% of the audience, and serves them right. This doesn't harm them at all, just displays a message at the top of the screen. That's just it: it is harmful, as now they're getting yelled at for something they didn't do. There's a reason why the web moved beyond this years ago, and it's depressing to see these solutions return. Moreover, consider the user who has no choice about what browser they use.
You obviously have not built antennas for HF then where it's EXTREMELY easy to built a antenna that causes losses. Like I said, only if you're incompetent
Fixed point to point (unlicensed) is restricted to 4 watts EIRP(unless things have changed since 2002 when this http://www.wi-fiplanet.com/tutorials/article.php/1 144391 was wrote. That's not even what the article says, learn to read. It very specifically says, "For antennas with gain greater than 6 dBi, the FCC requires you to reduce the transmitter output power if the transmitter is already at the maximum of 1 watt. The reduction, however, is only 1 dB for every 3 dB of additional antenna gain beyond the 6 dBi mentioned above. This means that as antenna gain goes up, you decrease the transmitter power by less. Thus, the FCC allows EIRP greater than 4 watts for antennas having gains higher than 6 dBi. Of course these higher gain antennas would mostly apply to point-to-point solutions having longer-range requirements, which is not common for most indoor applications," (emphasis mine); actually, this portion of the rule applies to fixed, point-to-point systems only. Non-point-to-point systems are limited to 36 dBm. The article is in keeping with my post above, which was derived from the applicable Part 15 rules directly.
I need to correct myself. For omni-directional systems, the maximum ERP is 36 dBm (about 4W), allowing for 30 dBm of transmitter power and 6 dBi of antenna gain.
Power requirements are MORE then just the transmitter power. FCC ALWAYS uses ERP or Effective Radiated Power for measurement. No shit, and my statements aren't contradictory with this fact. And actually, no, they don't, always use ERP in all bands under all different parts. Part 97 isn't ERP restricted, but rather transmitter PEP restricted. Had you said 'Part 15', you'd be correct, of course.
Only way to tell is to measure it. Or you know, take the manufacturer's numbers and add them together, and compare them to the rules. The FCC will not fine if you, in good faith, designed your system by the numbers and they found that something performed better than specified. Especially given the fact that numbers are most likely to be high, not low.
Of course there are third party antennas that will work. Otherwise, they would not be able to SELL them.
Not quite true. You don't need a ham radio license to buy a ham radio transmitter, necessarily, nor is the sale illegal. The operation would be, but for many devices, including antennas, the onus isn't on the seller to ensure legal operation.
The ducks Linksys makes usually do not provide ANY gain. In fact, they usually cause a power loss. Nope, they're usually 2dBi or so, which is a small gain. It's pretty hard to build an antenna that causes loss, if you're even remotely competent.
If the AP you have is UNDER the required wattage, then you MAY be able to get away with a higher gain antenna. Seeing as the ERP requirement for omni-directional systems is 1W (30 dBm), and most consumer units have output in the 15 mW range (11.7 dBm), you have a lot of room. And the rules are different for fixed, point-to-point systems, allowing for almost 100W (50 dBm).
There is just no way they can maintain 300 miles/480km without using relay stations.
Yes, they can, from two moutain tops with clear line-of-sight at the horizion.
It would be difficult, but not impossible. Hams have done >200mi distances before on the microwave bands. 300mi is tough, and 300mi on 802.11b would be very difficult.
Anyone else, like 90 percent of us who use WiFI, it's not legal. Nope. This is utter tripe. As long as you stay within the power requirements for Part 15 operation, you're legal. Doesn't matter what antenna you use.
Only the antenna that comes with your equipment or is designed for use with that equipment (like DESIGNED to work with it)can guarantee that you stay udner the FCC's regulated ERP rules. Well, duh. But there's tons of 3rd-party antennas that are designed to worth with consumer equipment and not exceed part 15 regulations.
An even better solution would be to have the source code on the computer, and have the machine compile the patches locally from a (much quicker to patch) source code.
No, it really wouldn't, seeing as the Windows source takes days for a full build. The install size alone difference would make this a fucking retarded solution.
Except the XML file tells the parser where its own definition is. Each of the XML files inside of an OO.o package tell you how to figure out what they are. It's not quite that simple. XML files have two definitions: the DTD and the schema. The DTD is required for validation (i.e., well-formed XML), the schema for retreiving the layout of about the elements (i.e., an integer goes in the foo attribute). Neither are required for an XML document (though you must have a DTD if you want to validate it). Schemas aren't required at all, and that's what you want if you really to be able to progmatically manipulate XML without knowing anything it's form. Even then, they may not very useful; they'll tell you what's legal content in a element, but they still tell you nothing about what's supposed to go into to that element (i.e., what does the data stored in element 'foo' mean)? DTDs are useless for telling you anything about the content as well; they are a holdover from the SGML days.
I should go further to point out that OO does define DOCTYPES, but doesn't define any XML Schema information. Even if it did, that still doesn't tell me what the tag 'font-attribute' means. You still have to structure your XML schema in such a manner that a human can interpret meaning. So 'human-readable' is still in the eye of the beholder. XML doesn't go any further to rectify this than any other format. Making your data XML doesn't automatically make it human-readable. It's just like naming variables in a programming language: the name is arbitrary, but a good name will tell me what the variable is supposed to be holding (e.g., 'tmp' vs. 'lookup_value').
As an aside, were you referring to the xmlns declaration when you said, "A generic XML parser can at least find the URI to the file's type definition"? Those don't actually have any real-world meaning. They exist solely to let the XML parser know that the namespace I call 'foo' in one document and the namespace I call 'bar' in the second document are the same namespace. They don't have to have any real-world relevance (though they often do). They play no role in valdiation besides for the namespace identification I mentioned. If you look up the namespaces even for 'offical' XML groups you'll see they usually link to their documentation, not to a DTD or anything. Some parsers do smart things with some of the well-known namespace URIs, but there is no requirement for them to do so AFAIK.
It might be more accurate to say that Java forbids buffer overflows. Attempts at C and C++ buffer overflows yield undefined behavior. For example, if p points to a 1-element array, *(p+1) is undefined. And (p+2) is undefined, even without a dereference.
Despite the name, an implementation is allowed to define "undefined behavior" (C99 3.4.3, C++98 1.3.12), and could map it to some safe behavior, such as raise(SIGABRT). Actually doing this would be quite a bit of overhead. The resulting environment might be even slower than JRE, if that is possible.:-)
All operating systems handle this particular "undefine behavior" in a safe and efficent manner. On Linux, it's called SIGSEGV. If you access memory outside your process space, you're killed.
The BSD license is making that decision for me. No, you made that decision when you chose to license your code under the BSD license. Scapegoating an inanimate document is childish. BTW, if you can't comprehend the full ramifications of a specific license, then don't use it.
If you want to contribute to a project licensed under me, then you MUST contribute your code to proprietary software vendors that want to use it Incorrect. The BSD license does not forbid someone distributing BSD-licensed code from limiting distribution. It doesn't mandate it either. It also doesn't forbid you from charging whatever you want for distribution as well. IOW, there's nothing illegal about licensing your code under a BSD license and then only giving it to certain people. However, you can't force them to do the same. BTW, the GPL is exactly the same way; neither license makes any statement about who can/cannot be distributed to. The GPL does differ in that you cannot charge for source distribution. The expectation is that you give it to everyone freely, but that's not the legal requirement.
The GPL gives me freedom to decide how the code will be used in proprietary software. Actually, it doesn't give you the choice, it mandates it for you. The GPL requires open-sourcing of any changes made, this kills any proprietary software. The BSD does not. Like it or not, logically, this means the BSD license is more free than the GPL in this regard, because more choices are available. This isn't something that can be argued either.
The BSD license may force a situation (if you're required to license under the BSD license, which, without forking, you generally are for BSD projects), but the GPL merely has the absense of that force. This is backwards.
Generally it's a strange definition of freedom that denies it to contributors. It's also a strange one that denies it to it's users.
Not at all. What I'm saying is that it's a page that was meant to discredit MySQL by putting together a sort of reverse-FAQ. Given the author has a page for PostgreSQL as well (albeit a short one), I'd suggest you're full of shit.
it's just a diatribe about how lacking someone thinks MySQL is. Since when is pointing out things that a piece of software does incorrectly, especially when it claims to do them correctly and noting the relevant examples and documentation to do that, a diatribe?
That, as they say, ain't news, and it most CERTAINLY does not deserve a fresh link from every MySQL article to hit Slashdot. Perhaps it does, so people think twice about using MySQL. I'm all for the right tool and all, but your argument on why it shouldn't be posted (or why it's wrong) makes no sense (logically or emotionally) whatsoever.
Actually, PNG has the particular issue that the colormap is not compressed. They should have just compressed the whole stream. They should also add an option (required by all readers) to use BZIP2 compression, since it does a much better job than GZIP on most images and the BZIP2 library is just as open and has the same interface as ZLIB. Excpet that bzip is a block compression algorithm, meaning the files have to be multiples of a fixed sized. For web images, you just negated the advantage you got from increasing the compression anyway.
Slashdot Mirror
Nice feature to have, but people have been using postgres (and other databases) sucessfully for years. How did they work around it?
You either move the blocking operation elsewhere (i.e., a trigger) or you don't. Data consistency is more important than performance (normally). The user can wait.
My only beef with PgSQL has been there since before the 7's. There is still no way to not show the list of databases to users who have no right or access to those databases.
Because, unless you configure pg_hba.conf to forbid them from authenticating to that database, all users have the privilege to connect to any database they wish. They may not be able to do anything, but they can connect. IOW, what databases you can connect to are handled by the connection authentication mechanisms, and the GRANT system has no control over it.
When you think about it, this really makes a ton of sense.
A sufficiently determined intruder or experienced wireless security guru will have no trouble sniffing valid MACs.
Umm, no. Anyone who can sniff wireless frames gets to see the MAC addresses involved: they're part of every frame.
However, this precaution - more than anything - deters the less technologically savvy wardrivers/what-have-you that are causing most headaches.
There is nothing conclusive out there to show this.
The problem with facile generalizations is that they generally aren't true -- pun intended.
Wonderful, show this specific one isn't true.
Every time you add a layer of security, no matter how thin, you weed out another percentage of "mad leet haxors".
Didn't you just say, 'The problem with facile generalizations is that they generally aren't true -- pun intended.'? An response consisting solely of logical fallicies doesn't merit much weight. You can't demonstrate this is true in all cases, so you fall victim to your first statement.
A determined professional can crack almost anything, but even "useless" measures like MAC filtering go a ways toward dissuading amateurs.
That's just the thing, MAC filtering doesn't. The overwhelming majority of wireless adapters can change MAC addresses (hell, I have first-generation 802.11b consumer gear that can do it) and anyone with ability to run kimset or AirSnort and correctly interpret it's output can change a MAC address, especially in Windows.
The gain is really zero, because it's such a trivial measure to defeat. Copy and paste. If the attacker can't manage that, one has to question their ability to successfully crack your wireless key and enter into their machine correctly in the first place.
Next time, try understanding a bit about the situation before posting that I might be wrong, simply because generalizations aren't always true.
I'm not even sure how shit like this gets posted. Editors need to learn to be fucking editors, and not bloggers.
The entire discussion of what's wrong with the IV usage under WEP is wrong. As is the "vulnerabilities" of CRC-32. It has no cryptographic purpose: it's intent is to ensure data integrity (i.e., not corrupted due to radio interference).
Anyone with any professional wireless experience knows that MAC filtering is a useless security measure, and shouldn't be bothered with.
There's more, but there's no real need to waste words on this tripe.
If they want to pretend to be IE, then that means they want to see messages that IE users see.
You're missing the point. The point is: you shouldn't care what the user's browser is in the first place.
Why else would they set their user-agent to IE?
Because of retarded sites that send broken pages to other UAs?
That's exactly why it's only a message telling users to switch, instead of blocking the whole site off from IE. The user who has no choice about what browser they use can just skip that message.
YOu missed the point. The point is, you're essentially telling a portion of your userbase (perhaps a substantial one) that they're inferior due to a choice they have no control over.
They are >1% of the audience, and serves them right. This doesn't harm them at all, just displays a message at the top of the screen.
That's just it: it is harmful, as now they're getting yelled at for something they didn't do. There's a reason why the web moved beyond this years ago, and it's depressing to see these solutions return.
Moreover, consider the user who has no choice about what browser they use.
Except that other browsers pretend to be IE (e.g., Opera) or can be configured to pretend as such (e.g., Konqueror, Safari).
The above is the exact reason why browser detects are no longer used in Javascript: The user agent doesn't tell you jack or shit.
You obviously have not built antennas for HF then where it's EXTREMELY easy to built a antenna that causes losses.
Like I said, only if you're incompetent
Fixed point to point (unlicensed) is restricted to 4 watts EIRP(unless things have changed since 2002 when this http://www.wi-fiplanet.com/tutorials/article.php/1 144391 was wrote.
That's not even what the article says, learn to read. It very specifically says, "For antennas with gain greater than 6 dBi, the FCC requires you to reduce the transmitter output power if the transmitter is already at the maximum of 1 watt. The reduction, however, is only 1 dB for every 3 dB of additional antenna gain beyond the 6 dBi mentioned above. This means that as antenna gain goes up, you decrease the transmitter power by less. Thus, the FCC allows EIRP greater than 4 watts for antennas having gains higher than 6 dBi. Of course these higher gain antennas would mostly apply to point-to-point solutions having longer-range requirements, which is not common for most indoor applications," (emphasis mine); actually, this portion of the rule applies to fixed, point-to-point systems only. Non-point-to-point systems are limited to 36 dBm. The article is in keeping with my post above, which was derived from the applicable Part 15 rules directly.
I need to correct myself. For omni-directional systems, the maximum ERP is 36 dBm (about 4W), allowing for 30 dBm of transmitter power and 6 dBi of antenna gain.
Power requirements are MORE then just the transmitter power. FCC ALWAYS uses ERP or Effective Radiated Power for measurement.
No shit, and my statements aren't contradictory with this fact.
And actually, no, they don't, always use ERP in all bands under all different parts. Part 97 isn't ERP restricted, but rather transmitter PEP restricted. Had you said 'Part 15', you'd be correct, of course.
Only way to tell is to measure it.
Or you know, take the manufacturer's numbers and add them together, and compare them to the rules. The FCC will not fine if you, in good faith, designed your system by the numbers and they found that something performed better than specified. Especially given the fact that numbers are most likely to be high, not low.
Of course there are third party antennas that will work. Otherwise, they would not be able to SELL them.
Not quite true. You don't need a ham radio license to buy a ham radio transmitter, necessarily, nor is the sale illegal. The operation would be, but for many devices, including antennas, the onus isn't on the seller to ensure legal operation.The ducks Linksys makes usually do not provide ANY gain. In fact, they usually cause a power loss.
Nope, they're usually 2dBi or so, which is a small gain. It's pretty hard to build an antenna that causes loss, if you're even remotely competent.
If the AP you have is UNDER the required wattage, then you MAY be able to get away with a higher gain antenna.
Seeing as the ERP requirement for omni-directional systems is 1W (30 dBm), and most consumer units have output in the 15 mW range (11.7 dBm), you have a lot of room. And the rules are different for fixed, point-to-point systems, allowing for almost 100W (50 dBm).
There is just no way they can maintain 300 miles/480km without using relay stations.
Yes, they can, from two moutain tops with clear line-of-sight at the horizion.It would be difficult, but not impossible. Hams have done >200mi distances before on the microwave bands. 300mi is tough, and 300mi on 802.11b would be very difficult.
Anyone else, like 90 percent of us who use WiFI, it's not legal.
Nope. This is utter tripe. As long as you stay within the power requirements for Part 15 operation, you're legal. Doesn't matter what antenna you use.
Only the antenna that comes with your equipment or is designed for use with that equipment (like DESIGNED to work with it)can guarantee that you stay udner the FCC's regulated ERP rules.
Well, duh. But there's tons of 3rd-party antennas that are designed to worth with consumer equipment and not exceed part 15 regulations.
Who modded this tripe up?
No, it really wouldn't, seeing as the Windows source takes days for a full build. The install size alone difference would make this a fucking retarded solution.
You can't copy an encrypted DVD because DVD-R media (of all forms) has the block where the encryption keys go zeroed out.
Except you're wrong about the address. ::ffff:66.35.250.150
It's
Except the XML file tells the parser where its own definition is. Each of the XML files inside of an OO.o package tell you how to figure out what they are.
It's not quite that simple. XML files have two definitions: the DTD and the schema. The DTD is required for validation (i.e., well-formed XML), the schema for retreiving the layout of about the elements (i.e., an integer goes in the foo attribute). Neither are required for an XML document (though you must have a DTD if you want to validate it). Schemas aren't required at all, and that's what you want if you really to be able to progmatically manipulate XML without knowing anything it's form. Even then, they may not very useful; they'll tell you what's legal content in a element, but they still tell you nothing about what's supposed to go into to that element (i.e., what does the data stored in element 'foo' mean)? DTDs are useless for telling you anything about the content as well; they are a holdover from the SGML days.
I should go further to point out that OO does define DOCTYPES, but doesn't define any XML Schema information. Even if it did, that still doesn't tell me what the tag 'font-attribute' means. You still have to structure your XML schema in such a manner that a human can interpret meaning. So 'human-readable' is still in the eye of the beholder. XML doesn't go any further to rectify this than any other format. Making your data XML doesn't automatically make it human-readable. It's just like naming variables in a programming language: the name is arbitrary, but a good name will tell me what the variable is supposed to be holding (e.g., 'tmp' vs. 'lookup_value').
As an aside, were you referring to the xmlns declaration when you said, "A generic XML parser can at least find the URI to the file's type definition"? Those don't actually have any real-world meaning. They exist solely to let the XML parser know that the namespace I call 'foo' in one document and the namespace I call 'bar' in the second document are the same namespace. They don't have to have any real-world relevance (though they often do). They play no role in valdiation besides for the namespace identification I mentioned. If you look up the namespaces even for 'offical' XML groups you'll see they usually link to their documentation, not to a DTD or anything.
Some parsers do smart things with some of the well-known namespace URIs, but there is no requirement for them to do so AFAIK.
So some freelance writer makes a store for /. and all of the sudden it's the offical F/OSS "State of the Union".
CmdrTaco, guys, nice try, but you need to quit stroking your egos now.
This is probably the worst article ever.
Anyone who tells you to disable DNS client on Windows is full of shit.
As such, a sane person is forced to conclue that their host file must be as well.
It might be more accurate to say that Java forbids buffer overflows. Attempts at C and C++ buffer overflows yield undefined behavior. For example, if p points to a 1-element array, *(p+1) is undefined. And (p+2) is undefined, even without a dereference.
Despite the name, an implementation is allowed to define "undefined behavior" (C99 3.4.3, C++98 1.3.12), and could map it to some safe behavior, such as raise(SIGABRT). Actually doing this would be quite a bit of overhead. The resulting environment might be even slower than JRE, if that is possible. :-)
All operating systems handle this particular "undefine behavior" in a safe and efficent manner. On Linux, it's called SIGSEGV. If you access memory outside your process space, you're killed.
But that's the point.
No, it isn't.
The BSD license is making that decision for me.
No, you made that decision when you chose to license your code under the BSD license. Scapegoating an inanimate document is childish.
BTW, if you can't comprehend the full ramifications of a specific license, then don't use it.
If you want to contribute to a project licensed under me, then you MUST contribute your code to proprietary software vendors that want to use it
Incorrect. The BSD license does not forbid someone distributing BSD-licensed code from limiting distribution. It doesn't mandate it either. It also doesn't forbid you from charging whatever you want for distribution as well.
IOW, there's nothing illegal about licensing your code under a BSD license and then only giving it to certain people. However, you can't force them to do the same. BTW, the GPL is exactly the same way; neither license makes any statement about who can/cannot be distributed to. The GPL does differ in that you cannot charge for source distribution. The expectation is that you give it to everyone freely, but that's not the legal requirement.
The GPL gives me freedom to decide how the code will be used in proprietary software.
Actually, it doesn't give you the choice, it mandates it for you. The GPL requires open-sourcing of any changes made, this kills any proprietary software. The BSD does not. Like it or not, logically, this means the BSD license is more free than the GPL in this regard, because more choices are available. This isn't something that can be argued either.
The BSD license may force a situation (if you're required to license under the BSD license, which, without forking, you generally are for BSD projects), but the GPL merely has the absense of that force.
This is backwards.
Generally it's a strange definition of freedom that denies it to contributors.
It's also a strange one that denies it to it's users.
Not at all. What I'm saying is that it's a page that was meant to discredit MySQL by putting together a sort of reverse-FAQ.
Given the author has a page for PostgreSQL as well (albeit a short one), I'd suggest you're full of shit.
it's just a diatribe about how lacking someone thinks MySQL is.
Since when is pointing out things that a piece of software does incorrectly, especially when it claims to do them correctly and noting the relevant examples and documentation to do that, a diatribe?
That, as they say, ain't news, and it most CERTAINLY does not deserve a fresh link from every MySQL article to hit Slashdot.
Perhaps it does, so people think twice about using MySQL. I'm all for the right tool and all, but your argument on why it shouldn't be posted (or why it's wrong) makes no sense (logically or emotionally) whatsoever.
OMG I'm DRNKA LOL !!!!!!111ononeoneone
Like, and then the RAs broke up the party. They suck.
Actually, PNG has the particular issue that the colormap is not compressed. They should have just compressed the whole stream. They should also add an option (required by all readers) to use BZIP2 compression, since it does a much better job than GZIP on most images and the BZIP2 library is just as open and has the same interface as ZLIB.
Excpet that bzip is a block compression algorithm, meaning the files have to be multiples of a fixed sized. For web images, you just negated the advantage you got from increasing the compression anyway.
No, cygwin provides a posix library that allows Windows applications to pretend to be Unix ones.
The binary format of a cygwin app is that of a windows app.
The article is talking about binary emulation, where apps compiled for Linux are run on Windows.