The school described the strip-search as 'not excessively intrusive in light of [the student's] age and sex and the nature of her suspected infraction.'
So what could excessively intrusive have been in this case? Surgically cutting her open and checking all internal organs?
If gravitational waves can shake a superconducting sheet, will shaking a superconductive sheet create gravitational waves? Wouldn't that open things up to some amazing experiments?
Yes, yes, I can see it now.. this could revolutionize everything from watch making to watch repair!
It's a router, not something of any great intrinsic value. Nuke the firmware and start over. (Reset, boot_wait, JTAG - lots of ways to nuke a new firmware into these things without having network access to them. Listed previously are some good terms to Google for.)
I'm just curious; if the malware alters the flash memory, how can you trust the reflash functionality? Is there some kind of unmodifiable boot ROM that the boot_wait functionality runs from, i.e. it works even if you rewrite every byte of the flash with zero?
I was using wget and wanted to have it download just the first N bytes of a file, so I could preview a bunch from a directory, then finish downloading only those that I liked. It didn't have this feature, so I downloaded the source code and added it in about 30 minutes (and I'm not at all familiar with Unix build scripts, nor do I regularly do this). It was very useful to have the source code.
Exactly; perhaps healthy people simply choose to live in cities with less air pollution. Even if air pollution had no actual effect on one's health, people concerned with health might still believe it did. Before anyone rebuts what I just said, please remember that I said "perhaps" and "might".
I have gotten exactly one spam message that has made it past Gmail's spam filtering this year (2009) and it was quick and easy to delete. I don't give my e-mail address out to everyone, but I do sign up to many things with it yet still it is very rare for spam to make it to even my spam filter. So is spam really that large of problem in 2009?
I have seen exactly one malware on my machine that my virus scanner picked up and it was quick and easy to delete. I don't leave all my machine's ports open, but I do leave several vulnerable ones open yet it is still very rare for any of the malware's operation to be noticeable to me. So is malware really that large of a problem in 2009?
Your post involves a knee-jerk response. The original poster wasn't proposing a spam solution, merely asking whether dedicated spam servers would make it easier to simply blacklist them.
Come on, do you think the US would share its submarine locations with other countries? That would be the only way to avoid collisions like this. Wait, there was no other country's vessels involved? Hmmm...
A spokesman for the 5th Fleet said that the USS Hartford suffered no damage to its nuclear propulsion system.
Will cost me about 1085 Pounds as a student (incl. wireless mouse/keyboard), but for this money I get a computer which provides me with excellent value for the price
Mac apparently keep resale value better, too: 1, 2, 3, 4
Children will say that my pastor showed me a picture of the dinosaurs and the cavemen living together. The teacher will explain that there is a difference between a painting and a photograph, and that with a certain skill, one can paint a picture of anything that looks reasonably like a near-photo.
I think I'd just tell the kids that there weren't any cameras back then.
Pointless consumers whose lives are devoted to working and shopping discover they can't afford to shop any more, yet have no idea what to do with their free time other than going to the mall.
I've got the perfect business plan: charge for admission to the store, kind of like a safari! "We have an exotic selection of specimens on display. Over here we have Compact Discus, which has recently been put on the endangered business method list."
If the default configuration is "hose my box, but do it really fucking fast", then it isn't just difficult to use, but it is badly designed. There is no excuse for bad design.
So then it gets to the point I touched on above: if the filesystem was meant for specialized uses, then it's the fault of the person putting it out there as useful on normal desktop machines.
In this case it sounds like the filesystem was just taking advantage of some aspects of the API that previous ones didn't, ones that broke programs that made bad assumptions. If this is true, I'd side with you that these everyday-program breaking features should have been off by default. The logic is that even though the API allowed them, the fact that they were never utilized basically removed that allowance from the commonly-accepted meaning of the API.
The proper approach is then to extend the API in a backwards-compatible way that allows specialized programs to get better performance, but for everyday programs to not need to do anything special to have basic data integrity. The fact that the original API allowed such behavior is a dry technical point.
My point was simply that IF a filesystem traded robustness for performance, we should blame the user for using it inappropriately. On ther hand, if the filesystem simply threw away robustness, without any performance benefit, and when being robust wasn't a significant design challenge, THEN we can rightly criticize the design. It merely being difficult to use (in a way unavoidable without throwing away performance) is not a reason to criticize it, because such criticism treats one possible use of the filesystem as the ONLY possible use. This is what the original poster seemed to be doing, since he was focusing only on its fragility, rather than fragility + no performance benefit (I don't know whether ext4 provides no corresponding benefit, just noting what I didn't see in the original argument). I really dislike arguments that suggest that we should only design for normal uses, and never design more specialized things that trade off generality for other desirable characteristics.
In fact, if order of operations makes it possible to end up with a corrupt file after a crash, it may well be possible that this could happen even if you do an fsync(). The system can still crash in the middle of your fsync(), and if at any time, the filesystem produces something inconsistent on disk, you can end up with a problem. No filesystem should ever be coded that intentionally creates inconsistent data on disk, however transient. Imagine a DBMS doing that.
Yes, not being able to make an entire operation atomic would be a big drawback! It'd be like doing multithreaded programming without locks, because you found that it was very rare for both to try to say increment a shared integer at the same moment.
Too bad it doesn't have something like Apple has had for ages, even in Mac OS Classic: FSExchangeObjects(). This call atomically exchanges two files; either the old file is intact on disk, or the new one's data is in its place. It seems that something is needed to signal to the filesystem that the rename is part of such an exchange operation, as opposed to a plain rename. But I don't know the details; perhaps the current interface already provides the filesystem enough information to determine when an exchange is occurring.
I mean I could write a spec for a file system that says "No write is guaranteed to be written to disk until the OS is shut down, everything can be cached in RAM for an indefinite amount of time." However that'd be real flaky and lead to data loss. That makes my FS useless. Doesn't matter if it is well documented, what matters is that the damn thing loses data on a regular basis.
Well, said design wouldn't be flaky and guarantee data loss in all environments, it'd just be fragile (and probably not give much of a performance benefit over one that flushed more often). Still using your hypothetical example, what if its behavior DID allow drastic performance improvements over anything less fragile? Having it available would offer users another option to choose when the benefits outweighed the fragility. If the developer documented the fragility clearly, what would be the problem? There would be no obligation to use it, just the option. Some filesystems will require different programming strategies, though will make it seem that normal strategies will work even though they will fail subtly.
Delayed block allocation allows the filing system to optimise its write processes, but at the price that the metadata of a newly created file will display a size of 0 bytes and occupy no data blocks until the delayed allocation takes place. [...] And now my question: Why did the Ext4 developers make the same mistakes Reiser and XFS both made (and later corrected) years ago? [...] Those who fail to learn the lessons of [change] history are doomed to repeat it.
They tried to, but history was just a 0-byte file.
Funny how they admit flaws when they lose the election.
Why would they admit non-existent flaws when the machines correctly ignored the votes cast, and properly logged deletions when the machines were being watched?
or it will lead to even more stagnation as the little innovative guys, the ones who are ultimately responsible for significant changes in culture many years down the road, will never see a penny and cultural development will become glacial.
So cultural development before copyright was glacial?
Slashdot Mirror
So what could excessively intrusive have been in this case? Surgically cutting her open and checking all internal organs?
But would tighting a major space probe be any different? I think not!
Yes, yes, I can see it now.. this could revolutionize everything from watch making to watch repair!
Google's cache still has the content.
I'm just curious; if the malware alters the flash memory, how can you trust the reflash functionality? Is there some kind of unmodifiable boot ROM that the boot_wait functionality runs from, i.e. it works even if you rewrite every byte of the flash with zero?
It's little-known that Bush also found some critical errors in Fermilab calculations.
If you want me to use your service and resources, then you don't get to dictate your terms to me.
I was using wget and wanted to have it download just the first N bytes of a file, so I could preview a bunch from a directory, then finish downloading only those that I liked. It didn't have this feature, so I downloaded the source code and added it in about 30 minutes (and I'm not at all familiar with Unix build scripts, nor do I regularly do this). It was very useful to have the source code.
Exactly; perhaps healthy people simply choose to live in cities with less air pollution. Even if air pollution had no actual effect on one's health, people concerned with health might still believe it did. Before anyone rebuts what I just said, please remember that I said "perhaps" and "might".
I have seen exactly one malware on my machine that my virus scanner picked up and it was quick and easy to delete. I don't leave all my machine's ports open, but I do leave several vulnerable ones open yet it is still very rare for any of the malware's operation to be noticeable to me. So is malware really that large of a problem in 2009?
Your post involves a knee-jerk response. The original poster wasn't proposing a spam solution, merely asking whether dedicated spam servers would make it easier to simply blacklist them.
Nono, it only finds exploits in open-source code. Microsoft code is safe from this evil tool. It's just another way they are attacking open source!
Come on, do you think the US would share its submarine locations with other countries? That would be the only way to avoid collisions like this. Wait, there was no other country's vessels involved? Hmmm...
Caterpillar drive by any chance?
Mac apparently keep resale value better, too: 1, 2, 3, 4
I think I'd just tell the kids that there weren't any cameras back then.
God might disagree.
I've got the perfect business plan: charge for admission to the store, kind of like a safari! "We have an exotic selection of specimens on display. Over here we have Compact Discus, which has recently been put on the endangered business method list."
So then it gets to the point I touched on above: if the filesystem was meant for specialized uses, then it's the fault of the person putting it out there as useful on normal desktop machines. In this case it sounds like the filesystem was just taking advantage of some aspects of the API that previous ones didn't, ones that broke programs that made bad assumptions. If this is true, I'd side with you that these everyday-program breaking features should have been off by default. The logic is that even though the API allowed them, the fact that they were never utilized basically removed that allowance from the commonly-accepted meaning of the API. The proper approach is then to extend the API in a backwards-compatible way that allows specialized programs to get better performance, but for everyday programs to not need to do anything special to have basic data integrity. The fact that the original API allowed such behavior is a dry technical point.
That's odd, it shows a different number of stars than your password really is. Guess that's to avoid giving even its length away. Clever!
Yes, not being able to make an entire operation atomic would be a big drawback! It'd be like doing multithreaded programming without locks, because you found that it was very rare for both to try to say increment a shared integer at the same moment.
Too bad it doesn't have something like Apple has had for ages, even in Mac OS Classic: FSExchangeObjects(). This call atomically exchanges two files; either the old file is intact on disk, or the new one's data is in its place. It seems that something is needed to signal to the filesystem that the rename is part of such an exchange operation, as opposed to a plain rename. But I don't know the details; perhaps the current interface already provides the filesystem enough information to determine when an exchange is occurring.
Well, said design wouldn't be flaky and guarantee data loss in all environments, it'd just be fragile (and probably not give much of a performance benefit over one that flushed more often). Still using your hypothetical example, what if its behavior DID allow drastic performance improvements over anything less fragile? Having it available would offer users another option to choose when the benefits outweighed the fragility. If the developer documented the fragility clearly, what would be the problem? There would be no obligation to use it, just the option. Some filesystems will require different programming strategies, though will make it seem that normal strategies will work even though they will fail subtly.
They tried to, but history was just a 0-byte file.
Why would they admit non-existent flaws when the machines correctly ignored the votes cast, and properly logged deletions when the machines were being watched?
So cultural development before copyright was glacial?