I "sang along at home" and compiled/executed the programs on a Pentium D system running Debian squeeze/sid, kernel is 2.6.31-ish. Everything worked as advertised, though the filesizes for the earlier examples were MUCH larger (about 2x). The final crazy-compacted nearly hand-assembled ELF file was the stated size.
Why SHOULD Linux check the fields it isn't interested in? That's a great way to break backwards-compatibility of programs that try to use new features. Now if you do something non-standard, your program won't be forward-compatible in case Linux STARTS caring about those fields, but that's on the programmer's shoulders. From what I read in the article, many of the ignored fields are "reserved for future functionality", which is specification-ese for, "allow absolutely any content to be placed here until further notice".
The only thing interesting about it was that the article pointed out an interesting fact -- Linux will run inappropriately formatted binaries. BAD. Linux kernel people? Are you reading this? Fix it before someone figures out how to use this in making and executing more exploits.
You're missing something here. Linux will execute "inappropriately formatted" binaries in that it completely ignores parts of the ELF header. This is not exploitable as you could just put that same data in the.data section and make the executable slightly larger. Executing the "bad" files does not allow the executed process any additional permissions, there's no security hole here. More like BAD ELF format authors putting in unused fields that just take up space:P
Also, while you might be familiar with all kind of assembler tricks (good for you), I for one wasn't, and I was quite intrigued.
Do you feel the same way about CPUs that are artificially limited to run at less than their capacity? Now in that case they aren't offering to sell you an unlock key to make it run at full speed, but I'm sure that's just because it's technically prohibitive to do so in a secure way. (or to be slightly less cynical, because of the bad PR it would generate)
On another but related topic, I wonder if there is a crack for the game that unlocks the DLC?
a cop going undercover to find out how criminals operate
This is a cop, who has an official, documented undercover task, but this man is a civilian associating with criminals on his own will. It is his duty to report the crime in progress.
Otherwise any gang member could say: "I am a sociologist. I was studying the way murderers and thieves operate and think. This is why I was on the crime scene."
Where does Hansen say he was "present at the crime scene"? I assume his contacts didn't give him any incriminating details, so what crimes in progress does he have a duty to report? If he did participate in any crimes, then he is obviously culpable. Otherwise it is a similar situation to a reporter interviewing a criminal, though again a security researcher is lacking the special protections reporters get for that sort of thing.
Probably you are lucky and were not a victim of these bot-nets and trojans' writers. But these are just about the same crime tools as picklock, gun, ax, etc. And these people are robbers, who just use some other tools.
No, I've had systems compromised quite a few times before I knew any better, and had to clean up after many people who have had their systems compromised as well. Although if you mean I haven't been a "serious victim" I guess you are correct, though that wouldn't change my attitude about it. Not studying the problem is a sure-fire way to remain vulnerable to it.
Your fascination with them is unjustified. It is like a person, who likes to knit, would be fascinated by a criminal, who, say, strangle people by a cord.
Let's see, my wife, who happens to knit, IS fascinated by forensic investigation documentaries, partially for the forensic part, but partially for the pathology of the criminal involved. I guess it runs in the family;)
But seriously, my point here is that interest does not equate with belief. Just because someone studies criminals (of any kind, I don't make a distinction between "regular" thieves and botnet operators) it doesn't mean that they approve of the crime.
One can well be a good talented programmer and not be fascinated by moral freaks, who use programming to commit crime.
Definitely, but I'm skeptical how good a security researcher you can be without being at least a little interested.
1. Regardless of your knee-jerk reaction to being interested in how "bad people" think, they ARE fascinating, and often very fruitful to study. 2. Assuming you didn't RTFA, I don't see anywhere where he glamorizes black hats. 3. This is akin to a cop going undercover to find out how criminals operate, you think they should be tossed in jail too?
Security research REQUIRES you to think like the "bad guys", it just comes with the territory.
I don't really see that a labelled break/continue is much different from a labelled goto.
Particularly when you have programmers who, when they are told "no gotos", they just synthesize them out of other programming constructs so that they aren't "technically" gotos. Example: void some_function( ) {
do {
some processing;
if( test for fatal error )
break;
some more processing;
} while( 0 ); return; }
Isn't that lovely? No gotos, there, except that that it generates exactly the same code that a goto would have, and is either marginally more readable or very less readable, depending on whether the while(0) construct confuses you or not.
This is so true, I think programmers need experience with a language that doesn't do hand-holding so they can learn for themselves why structured programming is so important. This is something I found very lacking with my CS degree (ymmv of course), we were told why rigorous design is necessary, but we were never exposed to systems sufficiently complex to show us the pain that could be created by undisciplined coding.
I never saw just how bad it could be until I got into the workforce and had to maintain terrible code. That experience quickly changed my opinion from, "Software Engineering* seems to be a really good idea... in theory", to being certain of it's necessity to the point of looking my boss in the eye and telling him that no, I can't deliver on his deadline because we have code reviews and regression tests to do, and they are not optional.
I don't follow your argument, are you saying the architect must be consulted/paid in order to make changes to the blueprint, which usually occurs during any commercial construction, or that the architect has to be consulted for construction, regardless of whether the blueprint is involved or not?
In the first case, you are obviously correct, but in the second, I don't think the architect would have any rights to the actual building unless mandated separately by a contract.
"A local community organization has asked me to help them set up WiFi access for an upcoming event, with some unusual (to me) requirements. All users (up to 500 people) will occupy a relatively small area and more-or-less have line-of-sight to the WAP, so issues like signal strength and wall penetration don't matter. Security also does not matter, as we plan to open this to anyone wanting to connect."
Most large hotels offer conference facilities complete with WiFi access for attendees. This might be the easiest solution and the community organization might be able to negotiate a discount on a conference room. Plus the hotel will usually be able to offer catering service.
Indeed they do, and it usually consists of the linksys-or-three approach that was mentioned in the summary. While definitely easier, it is probably both more expensive and lower-performing than the submitter would manage without/.'s help.
Concerning the sentience or lack thereof in cows, chickens and pets:
Not that I disagree with your initial point, I agree that most food animals have been bred and/or raised such that they are basically automatons, but generalizing to all animals is perhaps a bit much. "feedstock" animals are both bred and raised in order to have no personality, it's a desirable trait in the industry. Also there are some pet animals that have no discernable personality (small, ornamental birds for example). However an animal that has been bred and raised to be a companion or worker is a very different beast (pun intended), and from what I've seen is worthy of being treated with at least some of the dignity and respect that we generally reserve for "real people". Somewhere in the continuum between eating-and-shitting food production machine and lifelong companion and friend there is a probably very broad and indistinct grey line, but I think there ARE animals on both sides of that line, and that the ones we deem to be on the side closer to us should be respected and protected.
Concerning your other argument, that such a list is not necessary since people (or at least the majority of people) who are animal abusers can be "fixed" and become safe such that a list of this kind is not necessary... I tend to have some sympathy for your view, since the animal abuse anecdotes I am aware of have almost universally had some element of "they aren't people, so it's ok" to it, rather than the compulsive, mental-illness kind of impetus child abuse seems to be frequently linked with. Many cases of animal abuse seem almost casual, which just drives animal rights activists crazy (crazier?), but on the plus side, if it IS casual, that means not as much disincentive needs to be applied to prevent the activity. All that aside though, I'd need to see some studies on the subject, particularly with regards to punishments applied and recidivism rates to develop a solid opinion on the subject..
The first potential improvement I thought of was outdoor levels. Sure it was convenient for both the tone of the game and for the type of puzzle to have everything take plave in mostly cramped indor rooms, literally being confined, but I think you could do some really interesting things with more open levels. And that is the kind of thing that takes longer to develop.
Quite a bit of the analysis seems to be reasonable on the surface, but something about the way it was presented set me off in a geek-rant that I put in the comments. Since I'm having trouble posting that comment on the site, here it is.
Many of the points sound reasonable, but the argument is strongly undermined by the fact that it offers not a single apples-to-apples comparison between ogg and any other container format in the article. On a section-by-section basis:
Generalities/codec mapping:
Article complains about how there is no global mapping, but does not assert that other containers have one.
Overhead:
The breakdown of where space is wasted is informative and mostly reasonable, but some of them seem to be a reach, such as the checksum being unneeded, and the suggestion of implementing the functionality in optional fields seems like a bad idea to me in general, since it will make the header variable-length, which is something to strongly avoid in my experience. Finally, when the article does "compare" ogg to mp4, it compares some rather hand-wavey numbers for ogg to a different scenario for mp4.
Latency:
The article fires off a bunch of numbers here, but then offers no comparison to the alternatives. In fact it don't even provide an explanation of how other formats avoid this latency in theory, much less in practice, and instead of showing how bad the latency is, it uses it as a platform to show that a naive reaction to the issue will cause bad header overhead.
Random Access:
In this section it lists quite a few worst-case numbers for disk accesses (why isn't it being pre-cached by the filesystem?) and then ends with no comparison to alternatives at all.
Complexity:
Once again it has a bunch of statements of problems the author has with the format, but no comparisons to "good" formats, in addition this section is particularly weak, with statements like, "implementation is annoying", and "ambiguity is bad".
Final Words:
"We have shown" is a rather specific claim to make, which the article has not remotely achieved. This pretty much sums up the whole article, which is titled "Ogg objections", but then tries in the text to bill itself as a rigorous analysis of ogg, which it is not.
If the author had matched the tone of the article to the title, this would be reasonable, but he only hurts his position when he throws around phrases like, "True generality is evidently not to be found with the Ogg format.", "The Ogg format is clearly not a good choice for a low-latency application.", and "We have shown the Ogg format to be a dubious choice in just about every situation.". He has demonstrated NONE of the above claims, and by making them the article has rendered me skeptical of the rest of its claims.
"fast-forwarding"... "commercials"... I seem to vaguely remember dealing with these concepts in my youth, I thought we had moved past such user-unfriendly concepts years ago.
Using an unsecured wifi is more like depositing mail in their unlocked mailbox to be picked up by the postman. (Not stealing their mail)
...so you're pushing the person closer to their cap without them even knowing about it, so you could push them in to receiving additional charges and costs incurred. It'd be like running an extension cord out their window and using their electricity to power your laptop, if power had usage caps instead of per-watt charges, which it doesn't. They're charged for what you're using if you use a completely excessive amount of bandwidth.
So in other words, it's Quantum theft. In all seriousness though, I understand that if done excessively, using someone's unsecured Wifi could cause them problems, either by making them exceed their bandwidth caps or by negatively impacting their service while you are using it. However you seem to be making an all-or-nothing thing out of this in that since you *could* cause them problems, then the practice is intrinsically wrong. I see no problem with it if your usage is not excessive.
I think you're missing the point here, the problem with RDBMSs isn't that they are "slow" per-se, which implies that they just need some good ol' fashioned optimization. The problem is that there is a cost associated with the data integrity guarantees they make (usually appears in scalability bottlenecks rather than in pure computational inefficiencies), regardless of how good the implementation is, and if you don't need some of those guarantees, you can dispense with them and end up with better performance (again, this typically means better scalability). Additionally, this is the kind of bottleneck that you just can't throw more resources at. Sure you can find the bottleneck and beef up that particular component to do more transactions/second, but at a certain point you've isolated the bottleneck on a world-class server that is doing nothing but that, and it's still a bottleneck. At that point (preferably long before you reach that point) you have to look at transitioning to an infrastructure that makes some kind of tradeoff that allows the removal of the bottleneck, which is what NoSQL does.
I doubt Twitter wants very many RDBMS-type data coherency guarantees at all. 160-character text strings with a similarly-sized amount of metadata, and no real-time delivery guarantees? Sounds like their database can get pretty inconsistent without messing things up badly. It seems to me they would be well served by using a database that offers just what they want/need in that area and better performance.
Oh and this:
Is there really a huge issue with rdbms speeds?
yes, and what are you smoking that you would even ask this question?
Only if you assume that the users will not now use a new set of 100 PINs. Additionally if you disallow easily-remembered PINs or passwords, the users will be forced to use less secure means of remembering their passwords, thus making the system as a whole easier to subvert.
"forcing" users to change their passwords is a particularly pernicious version of this, where while the user may have been happy to remember two rotating passwords, once the number of passwords in the disallowed history becomes larger, they tend to do things like adding an incrementing tag like password1 password2 and so on, and you are also increasing the risk that they will just start writing down a password, or emailing it to themselves plaintext, or otherwise making the chance of a compromise much higher.
If you are serious about securing a system instead of just making things more complicated, you need to seriously consider user-friendliness of the system, for example allowing a relatively long passphrase is a much better way to increase keysize than forcing your user to conform to some seemingly-arbitrary requirements like, "Your password must be between 8 and 15 characters, with no underscores, dashes, or spaces, but it must include at least 2 numbers and 1 special character". Also incompletely specifying your password rules is extremely non-user-friendly, for instance leaving out the "no spaces" requirement in the instructions provided to the user, but enforcing the rule by rejecting the password if it does contain spaces.
[rant]Also whoever came up with the idea of the "chose 3 from this list of completely random questions about yourself that you may or may not remember the precise answer to in two days, much less two months that we will demand that you answer every time that you log on to the system from a new computer" needs to be shot in the face repeatedly. Generally I can only find one of those at most that I actually have a concrete answer to that I will be sure to enter correctly, and those are almost always the ones that should definitely not be on the list, like "what is your mother's maiden name" or, "what is your favorite password"[/rant]
So once again we have more hoops for paying customers to jump through and perhaps have their legally purchased content automatically downgrade itself in order to "protect" the MPAA and member companies.
Meanwhile everyone who has given up on the ridiculously outdated and self-defeating content distribution system suffers no inconvenience whatsoever.
The further along this train wreck progresses the more my outrage turns into bemused detachment. I haven't bought any non-indie media in quite a long time now (occasionally I catch a movie or concert). I do feel somewhat sorry for the people who haven't figured out how totally messed up the system is and are going to be badly affected by this, but I just can't bring myself to the point of actual outrage over it any more.
How many people are going to just give up trying to be "good consumers" and switch over to piracy based on this? I would expect it will be far more people than will be dissuaded from participating in casual "copyright infringement" by trying to make backup copies of their media or god forbid just trying to watch a movie they bought on the wrong type of TV.
The main thing I would look at when determining whether to do a full re-write of the code rather than performing targeted re-factoring, is not the code itself, but the overall design. If the design is sound but badly implemented, you should be able to gradually refactor problem spots. If, on the other hand, the design itself is suspect or just plain wrong, it may be a candidate for a complete re-write (at this point you have to also look at business aspects of the process, such as how much change is expected to be made to this code in the future, and what kind of time constraints you have.)
A pair of examples from my immediate experience:
Two different dataloading protocols, layered on top of two different file transfer protocols, (furthermore each of them is layered on top of a different network protocol, but that is outside the scope of my project.) Each module was originally split across two applications running on seperate machines, the dataloading protocols were handled by one application on one machine, and the file transfer protocols were implemented on a second application running on a second machine (Don't ask, the project architecture is... interesting). The modules were tied together by a (really horrible) in-house message passing library. At some point lost in the mists of time, the programs were merged, this was done by making a new application that spawned both of the other programs as threads, but they were still tied together by the horrible message-passing library. After basically reverse-engineering a significant portion of the design and doing some performance analysis, I went to my higher-ups and presented my case for a re-write of one of the modules but not the other. The reasons were:
1. Module A had lots of bugs outstanding whereas module B was reasonably stable.
2. Module A had (has) significant features still to be added, whereas Module B was and is feature-complete.
3. Module A was at least somewhat modularized between the dataloading and file transfer protocols, which allowed re-writing one first, then the other, Module B's protocol layers were hopelessly intertwined, basically requiring a complete re-write of both layers at once.
1 and 2 were the main reasons, but 3 definitely is an issue. I'm still planning on trying to refactor Module B in-place to remove the terrible message-passing crap and replace it with a state machine, but that is extremely low priority.
I agree, the article writer picked some rather unimpressive offerings, but how about a pair of 1U dual-Xeon systems for $200? there is also a steady stream of other rackmount parts and accessories, along with misc memory, CPUs, and periphials. I understand that only a small fraction of the inventory makes it to the webpage, so I probably don't even see the good stuff:P
So why is it that when someone accomplishes something respectable (a.k.a. something you agree with) by "working smarter not harder" they get praised, but for some reason activists are supposed to eschew the use of force multipliers because it means "they aren't serious about it"? Do you really think MLKs followers would have gotten beaten, arrested, attacked by dogs, bruised by high-pressure water if they had any other option?
And finally, what have YOU done today to combat social injustice? At least the memebers of Annonymous are putting forth some effort, even if they aren't displaying the gumption of your old-school civil-rights strawman.
I know this was a joke, but it struck a chord with me. I started out in mobile, AL, where the best programming job I could find was about $33K a year working on an embedded RTOS (that pretty much tells you what company it was, but whatever). I took it, not realizing that I could easily do better elsewhere. Two years later looked around a bit more and landed a job doing higher-level systems programming targeting sort-of embedded Linux in Milwaukee, WI starting at $65K a year (the benefits, however were ok, but not as good). The moral of the story is to keep looking. If you pin yourself down to one region, you are severely limiting your options. Oh, and before someone says anything about cost of living differences, CoL in Milwaukee is *maybe* a few percent higher than in Mobile. Regardless it's completely dwarfed by the wage disparity.
Yes, the kernel is less stable between releases. I'm failing to see why this is an issue.
If you want a stable kernel, you can use a late release candidate, a release kernel, or one of the stable kernels. As an end user you can just punt and use a distribution's kernel, which will probably be on par with a stable kernel, but much larger since they have to support pretty much everything with a limited number of builds.
Distributions aren't picking up anyone's slack. What distributions do is pick a kernel version that has what they think is a good tradeoff between features and stability (with some other considerations I'm glossing over), and then proceed to tweak it for extra stability with their particular set of applications, often by cherry-picking stability fixes from continuing kernel development and backporting them to their target kernel. Note I'm NOT saying that is all they do, they often develop their own fixes, which sometimes get pushed upstream to mainstream kernel development. Then they continue to apply fixes to the kernel as they appear for longer than the kernel hackers are generally interested in doing.
Each distribution strikes a balance between features, stability, schedule, and other issues, and there are entirely too many distributions for the kernel hacker community to keep track of, much less address all their issues.
A final note, the dichotomy between distribution engineers and kernel hackers isn't all that clear a line, very often it's actually the same people doing the work on both sides of this imaginary fence.
That said, this device seems a bit overkill. Especially for a hacker. How about a simple relay switch powered by PIC or Atmel chip and a garage door opener.
I think the main reason would be if you don't have good line of sight to your car. In my case for example I'd be lucky to have it running for a minute before I arrived if I used a garage door opener, whereas if I used a cellphone I could start it when I left the building I work in and it would have the 5 minutes or so it takes to make the walk to start warming up.
Slashdot Mirror
I "sang along at home" and compiled/executed the programs on a Pentium D system running Debian squeeze/sid, kernel is 2.6.31-ish. Everything worked as advertised, though the filesizes for the earlier examples were MUCH larger (about 2x). The final crazy-compacted nearly hand-assembled ELF file was the stated size.
Why SHOULD Linux check the fields it isn't interested in? That's a great way to break backwards-compatibility of programs that try to use new features. Now if you do something non-standard, your program won't be forward-compatible in case Linux STARTS caring about those fields, but that's on the programmer's shoulders. From what I read in the article, many of the ignored fields are "reserved for future functionality", which is specification-ese for, "allow absolutely any content to be placed here until further notice".
The only thing interesting about it was that the article pointed out an interesting fact -- Linux will run inappropriately formatted binaries. BAD. Linux kernel people? Are you reading this? Fix it before someone figures out how to use this in making and executing more exploits.
You're missing something here. Linux will execute "inappropriately formatted" binaries in that it completely ignores parts of the ELF header. This is not exploitable as you could just put that same data in the .data section and make the executable slightly larger. Executing the "bad" files does not allow the executed process any additional permissions, there's no security hole here. More like BAD ELF format authors putting in unused fields that just take up space :P
Also, while you might be familiar with all kind of assembler tricks (good for you), I for one wasn't, and I was quite intrigued.
"I'm not shouting! Well perhaps I am. I'm shouting! I'm shouting! I'm shout*thud* *thump*"
Do you feel the same way about CPUs that are artificially limited to run at less than their capacity? Now in that case they aren't offering to sell you an unlock key to make it run at full speed, but I'm sure that's just because it's technically prohibitive to do so in a secure way. (or to be slightly less cynical, because of the bad PR it would generate)
On another but related topic, I wonder if there is a crack for the game that unlocks the DLC?
a cop going undercover to find out how criminals operate
This is a cop, who has an official, documented undercover task, but this man is a civilian associating with criminals on his own will. It is his duty to report the crime in progress.
Otherwise any gang member could say: "I am a sociologist. I was studying the way murderers and thieves operate and think. This is why I was on the crime scene."
Where does Hansen say he was "present at the crime scene"? I assume his contacts didn't give him any incriminating details, so what crimes in progress does he have a duty to report? If he did participate in any crimes, then he is obviously culpable. Otherwise it is a similar situation to a reporter interviewing a criminal, though again a security researcher is lacking the special protections reporters get for that sort of thing.
Probably you are lucky and were not a victim of these bot-nets and trojans' writers. But these are just about the same crime tools as picklock, gun, ax, etc. And these people are robbers, who just use some other tools.
No, I've had systems compromised quite a few times before I knew any better, and had to clean up after many people who have had their systems compromised as well. Although if you mean I haven't been a "serious victim" I guess you are correct, though that wouldn't change my attitude about it. Not studying the problem is a sure-fire way to remain vulnerable to it.
Your fascination with them is unjustified. It is like a person, who likes to knit, would be fascinated by a criminal, who, say, strangle people by a cord.
Let's see, my wife, who happens to knit, IS fascinated by forensic investigation documentaries, partially for the forensic part, but partially for the pathology of the criminal involved. I guess it runs in the family ;)
But seriously, my point here is that interest does not equate with belief. Just because someone studies criminals (of any kind, I don't make a distinction between "regular" thieves and botnet operators) it doesn't mean that they approve of the crime.
One can well be a good talented programmer and not be fascinated by moral freaks, who use programming to commit crime.
Definitely, but I'm skeptical how good a security researcher you can be without being at least a little interested.
Probably a troll, but I'll bite.
1. Regardless of your knee-jerk reaction to being interested in how "bad people" think, they ARE fascinating, and often very fruitful to study.
2. Assuming you didn't RTFA, I don't see anywhere where he glamorizes black hats.
3. This is akin to a cop going undercover to find out how criminals operate, you think they should be tossed in jail too?
Security research REQUIRES you to think like the "bad guys", it just comes with the territory.
I don't really see that a labelled break/continue is much different from a labelled goto.
Particularly when you have programmers who, when they are told "no gotos", they just synthesize them out of other programming constructs so that they aren't "technically" gotos. Example:
void some_function( ) {
do {
some processing;
if( test for fatal error )
break;
some more processing;
} while( 0 );
return;
}
Isn't that lovely? No gotos, there, except that that it generates exactly the same code that a goto would have, and is either marginally more readable or very less readable, depending on whether the while(0) construct confuses you or not.
This is so true, I think programmers need experience with a language that doesn't do hand-holding so they can learn for themselves why structured programming is so important. This is something I found very lacking with my CS degree (ymmv of course), we were told why rigorous design is necessary, but we were never exposed to systems sufficiently complex to show us the pain that could be created by undisciplined coding.
I never saw just how bad it could be until I got into the workforce and had to maintain terrible code. That experience quickly changed my opinion from, "Software Engineering* seems to be a really good idea... in theory", to being certain of it's necessity to the point of looking my boss in the eye and telling him that no, I can't deliver on his deadline because we have code reviews and regression tests to do, and they are not optional.
I don't follow your argument, are you saying the architect must be consulted/paid in order to make changes to the blueprint, which usually occurs during any commercial construction, or that the architect has to be consulted for construction, regardless of whether the blueprint is involved or not?
In the first case, you are obviously correct, but in the second, I don't think the architect would have any rights to the actual building unless mandated separately by a contract.
"A local community organization has asked me to help them set up WiFi access for an upcoming event, with some unusual (to me) requirements. All users (up to 500 people) will occupy a relatively small area and more-or-less have line-of-sight to the WAP, so issues like signal strength and wall penetration don't matter. Security also does not matter, as we plan to open this to anyone wanting to connect."
Most large hotels offer conference facilities complete with WiFi access for attendees. This might be the easiest solution and the community organization might be able to negotiate a discount on a conference room. Plus the hotel will usually be able to offer catering service.
Indeed they do, and it usually consists of the linksys-or-three approach that was mentioned in the summary. While definitely easier, it is probably both more expensive and lower-performing than the submitter would manage without /.'s help.
Here's one, I recall the coverage being better, perhaps you can find a better article once you have some of the details from this one though. http://www.washingtonpost.com/wp-dyn/content/article/2007/05/05/AR2007050501009_pf.html
Concerning the sentience or lack thereof in cows, chickens and pets:
Not that I disagree with your initial point, I agree that most food animals have been bred and/or raised such that they are basically automatons, but generalizing to all animals is perhaps a bit much. "feedstock" animals are both bred and raised in order to have no personality, it's a desirable trait in the industry. Also there are some pet animals that have no discernable personality (small, ornamental birds for example). However an animal that has been bred and raised to be a companion or worker is a very different beast (pun intended), and from what I've seen is worthy of being treated with at least some of the dignity and respect that we generally reserve for "real people". Somewhere in the continuum between eating-and-shitting food production machine and lifelong companion and friend there is a probably very broad and indistinct grey line, but I think there ARE animals on both sides of that line, and that the ones we deem to be on the side closer to us should be respected and protected.
Concerning your other argument, that such a list is not necessary since people (or at least the majority of people) who are animal abusers can be "fixed" and become safe such that a list of this kind is not necessary... I tend to have some sympathy for your view, since the animal abuse anecdotes I am aware of have almost universally had some element of "they aren't people, so it's ok" to it, rather than the compulsive, mental-illness kind of impetus child abuse seems to be frequently linked with. Many cases of animal abuse seem almost casual, which just drives animal rights activists crazy (crazier?), but on the plus side, if it IS casual, that means not as much disincentive needs to be applied to prevent the activity. All that aside though, I'd need to see some studies on the subject, particularly with regards to punishments applied and recidivism rates to develop a solid opinion on the subject..
The first potential improvement I thought of was outdoor levels. Sure it was convenient for both the tone of the game and for the type of puzzle to have everything take plave in mostly cramped indor rooms, literally being confined, but I think you could do some really interesting things with more open levels. And that is the kind of thing that takes longer to develop.
Quite a bit of the analysis seems to be reasonable on the surface, but something about the way it was presented set me off in a geek-rant that I put in the comments. Since I'm having trouble posting that comment on the site, here it is.
Many of the points sound reasonable, but the argument is strongly undermined by the fact that it offers not a single apples-to-apples comparison between ogg and any other container format in the article. On a section-by-section basis:
Generalities/codec mapping:
Article complains about how there is no global mapping, but does not assert that other containers have one.
Overhead:
The breakdown of where space is wasted is informative and mostly reasonable, but some of them seem to be a reach, such as the checksum being unneeded, and the suggestion of implementing the functionality in optional fields seems like a bad idea to me in general, since it will make the header variable-length, which is something to strongly avoid in my experience. Finally, when the article does "compare" ogg to mp4, it compares some rather hand-wavey numbers for ogg to a different scenario for mp4.
Latency:
The article fires off a bunch of numbers here, but then offers no comparison to the alternatives. In fact it don't even provide an explanation of how other formats avoid this latency in theory, much less in practice, and instead of showing how bad the latency is, it uses it as a platform to show that a naive reaction to the issue will cause bad header overhead.
Random Access:
In this section it lists quite a few worst-case numbers for disk accesses (why isn't it being pre-cached by the filesystem?) and then ends with no comparison to alternatives at all.
Complexity:
Once again it has a bunch of statements of problems the author has with the format, but no comparisons to "good" formats, in addition this section is particularly weak, with statements like, "implementation is annoying", and "ambiguity is bad".
Final Words:
"We have shown" is a rather specific claim to make, which the article has not remotely achieved. This pretty much sums up the whole article, which is titled "Ogg objections", but then tries in the text to bill itself as a rigorous analysis of ogg, which it is not.
If the author had matched the tone of the article to the title, this would be reasonable, but he only hurts his position when he throws around phrases like, "True generality is evidently not to be found with the Ogg format.", "The Ogg format is clearly not a good choice for a low-latency application.", and "We have shown the Ogg format to be a dubious choice in just about every situation.". He has demonstrated NONE of the above claims, and by making them the article has rendered me skeptical of the rest of its claims.
"fast-forwarding"... "commercials"... I seem to vaguely remember dealing with these concepts in my youth, I thought we had moved past such user-unfriendly concepts years ago.
Using an unsecured wifi is more like depositing mail in their unlocked mailbox to be picked up by the postman. (Not stealing their mail)
...so you're pushing the person closer to their cap without them even knowing about it, so you could push them in to receiving additional charges and costs incurred. It'd be like running an extension cord out their window and using their electricity to power your laptop, if power had usage caps instead of per-watt charges, which it doesn't. They're charged for what you're using if you use a completely excessive amount of bandwidth.
So in other words, it's Quantum theft. In all seriousness though, I understand that if done excessively, using someone's unsecured Wifi could cause them problems, either by making them exceed their bandwidth caps or by negatively impacting their service while you are using it. However you seem to be making an all-or-nothing thing out of this in that since you *could* cause them problems, then the practice is intrinsically wrong. I see no problem with it if your usage is not excessive.
I think you're missing the point here, the problem with RDBMSs isn't that they are "slow" per-se, which implies that they just need some good ol' fashioned optimization. The problem is that there is a cost associated with the data integrity guarantees they make (usually appears in scalability bottlenecks rather than in pure computational inefficiencies), regardless of how good the implementation is, and if you don't need some of those guarantees, you can dispense with them and end up with better performance (again, this typically means better scalability). Additionally, this is the kind of bottleneck that you just can't throw more resources at. Sure you can find the bottleneck and beef up that particular component to do more transactions/second, but at a certain point you've isolated the bottleneck on a world-class server that is doing nothing but that, and it's still a bottleneck. At that point (preferably long before you reach that point) you have to look at transitioning to an infrastructure that makes some kind of tradeoff that allows the removal of the bottleneck, which is what NoSQL does.
I doubt Twitter wants very many RDBMS-type data coherency guarantees at all. 160-character text strings with a similarly-sized amount of metadata, and no real-time delivery guarantees? Sounds like their database can get pretty inconsistent without messing things up badly. It seems to me they would be well served by using a database that offers just what they want/need in that area and better performance.
Oh and this:
Is there really a huge issue with rdbms speeds?
yes, and what are you smoking that you would even ask this question?
Only if you assume that the users will not now use a new set of 100 PINs. Additionally if you disallow easily-remembered PINs or passwords, the users will be forced to use less secure means of remembering their passwords, thus making the system as a whole easier to subvert.
"forcing" users to change their passwords is a particularly pernicious version of this, where while the user may have been happy to remember two rotating passwords, once the number of passwords in the disallowed history becomes larger, they tend to do things like adding an incrementing tag like password1 password2 and so on, and you are also increasing the risk that they will just start writing down a password, or emailing it to themselves plaintext, or otherwise making the chance of a compromise much higher.
If you are serious about securing a system instead of just making things more complicated, you need to seriously consider user-friendliness of the system, for example allowing a relatively long passphrase is a much better way to increase keysize than forcing your user to conform to some seemingly-arbitrary requirements like, "Your password must be between 8 and 15 characters, with no underscores, dashes, or spaces, but it must include at least 2 numbers and 1 special character". Also incompletely specifying your password rules is extremely non-user-friendly, for instance leaving out the "no spaces" requirement in the instructions provided to the user, but enforcing the rule by rejecting the password if it does contain spaces.
[rant]Also whoever came up with the idea of the "chose 3 from this list of completely random questions about yourself that you may or may not remember the precise answer to in two days, much less two months that we will demand that you answer every time that you log on to the system from a new computer" needs to be shot in the face repeatedly. Generally I can only find one of those at most that I actually have a concrete answer to that I will be sure to enter correctly, and those are almost always the ones that should definitely not be on the list, like "what is your mother's maiden name" or, "what is your favorite password"[/rant]
So once again we have more hoops for paying customers to jump through and perhaps have their legally purchased content automatically downgrade itself in order to "protect" the MPAA and member companies. Meanwhile everyone who has given up on the ridiculously outdated and self-defeating content distribution system suffers no inconvenience whatsoever.
The further along this train wreck progresses the more my outrage turns into bemused detachment. I haven't bought any non-indie media in quite a long time now (occasionally I catch a movie or concert). I do feel somewhat sorry for the people who haven't figured out how totally messed up the system is and are going to be badly affected by this, but I just can't bring myself to the point of actual outrage over it any more.
How many people are going to just give up trying to be "good consumers" and switch over to piracy based on this? I would expect it will be far more people than will be dissuaded from participating in casual "copyright infringement" by trying to make backup copies of their media or god forbid just trying to watch a movie they bought on the wrong type of TV.
A pair of examples from my immediate experience:
Two different dataloading protocols, layered on top of two different file transfer protocols, (furthermore each of them is layered on top of a different network protocol, but that is outside the scope of my project.) Each module was originally split across two applications running on seperate machines, the dataloading protocols were handled by one application on one machine, and the file transfer protocols were implemented on a second application running on a second machine (Don't ask, the project architecture is... interesting). The modules were tied together by a (really horrible) in-house message passing library. At some point lost in the mists of time, the programs were merged, this was done by making a new application that spawned both of the other programs as threads, but they were still tied together by the horrible message-passing library. After basically reverse-engineering a significant portion of the design and doing some performance analysis, I went to my higher-ups and presented my case for a re-write of one of the modules but not the other. The reasons were:
1. Module A had lots of bugs outstanding whereas module B was reasonably stable.
2. Module A had (has) significant features still to be added, whereas Module B was and is feature-complete.
3. Module A was at least somewhat modularized between the dataloading and file transfer protocols, which allowed re-writing one first, then the other, Module B's protocol layers were hopelessly intertwined, basically requiring a complete re-write of both layers at once.
1 and 2 were the main reasons, but 3 definitely is an issue. I'm still planning on trying to refactor Module B in-place to remove the terrible message-passing crap and replace it with a state machine, but that is extremely low priority.
I agree, the article writer picked some rather unimpressive offerings, but how about a pair of 1U dual-Xeon systems for $200? there is also a steady stream of other rackmount parts and accessories, along with misc memory, CPUs, and periphials. I understand that only a small fraction of the inventory makes it to the webpage, so I probably don't even see the good stuff :P
And finally, what have YOU done today to combat social injustice? At least the memebers of Annonymous are putting forth some effort, even if they aren't displaying the gumption of your old-school civil-rights strawman.
I know this was a joke, but it struck a chord with me. I started out in mobile, AL, where the best programming job I could find was about $33K a year working on an embedded RTOS (that pretty much tells you what company it was, but whatever). I took it, not realizing that I could easily do better elsewhere. Two years later looked around a bit more and landed a job doing higher-level systems programming targeting sort-of embedded Linux in Milwaukee, WI starting at $65K a year (the benefits, however were ok, but not as good). The moral of the story is to keep looking. If you pin yourself down to one region, you are severely limiting your options. Oh, and before someone says anything about cost of living differences, CoL in Milwaukee is *maybe* a few percent higher than in Mobile. Regardless it's completely dwarfed by the wage disparity.
Yes, the kernel is less stable between releases. I'm failing to see why this is an issue.
If you want a stable kernel, you can use a late release candidate, a release kernel, or one of the stable kernels. As an end user you can just punt and use a distribution's kernel, which will probably be on par with a stable kernel, but much larger since they have to support pretty much everything with a limited number of builds.
Distributions aren't picking up anyone's slack. What distributions do is pick a kernel version that has what they think is a good tradeoff between features and stability (with some other considerations I'm glossing over), and then proceed to tweak it for extra stability with their particular set of applications, often by cherry-picking stability fixes from continuing kernel development and backporting them to their target kernel. Note I'm NOT saying that is all they do, they often develop their own fixes, which sometimes get pushed upstream to mainstream kernel development. Then they continue to apply fixes to the kernel as they appear for longer than the kernel hackers are generally interested in doing.
Each distribution strikes a balance between features, stability, schedule, and other issues, and there are entirely too many distributions for the kernel hacker community to keep track of, much less address all their issues.
A final note, the dichotomy between distribution engineers and kernel hackers isn't all that clear a line, very often it's actually the same people doing the work on both sides of this imaginary fence.
That said, this device seems a bit overkill. Especially for a hacker. How about a simple relay switch powered by PIC or Atmel chip and a garage door opener.
I think the main reason would be if you don't have good line of sight to your car. In my case for example I'd be lucky to have it running for a minute before I arrived if I used a garage door opener, whereas if I used a cellphone I could start it when I left the building I work in and it would have the 5 minutes or so it takes to make the walk to start warming up.