Sure, she was dumb for wearing the board, but banned for good from airports?
People willfully disturbing public transportation should consider alternate means for transport. The concept is not hard to understand nor would the reasons be difficult to deduce. There is a reason why it is a federal crime to make jokes about bombs at airports. Not only did she joke but she manufactured an actual device which she used to perpetrate her federal crime. It doesn't sound she has any business to be in an airport period, let alone in a time of war. She actually sounds like the perfect candidate to be banned.
That is 100% incorrect. Airports are federally protected zones where lethal threat had been authorized. It would have been a fully legal to simply shoot her with a fully automatic weapon at the first hint of non-compliance.
A smart lawyer will do back flips to do everything possible to ensure she doesn't get jail time. It's likely she'll get banned from airports and/or aviation carriers.
I hate to say it, but you seem to be completely out of touch with reality. You need to go pick up a news paper and read what has been going on in the world for the last couple of years. Once you're up to speed with the rest of the adults, you'll understand why she is oh so lucky to be alive to talk about her stupidity.
Read my other comment. Hopefully it will put things into a more realistic perspective than you currently have.
I couldn't agree more. It's obvious she intended the device to be perceived as an explosive device. The facts we have:
Odd shirt with improvised electronics on it - detonator anyone? Putty (play-doh) like substance in hand - explosives anyone? She couldn't explain why she had it. Unresponsive to initial questions about her device by airport authorities We ARE at war Thousands have been murdered by people wearing this category of attire in the last year alone
So we have a stupid girl carrying what appears to be an explosive device while ignoring authority. She should have been shot to make sure this type of stupidity can't bread. She's lucky. IMO, any officer would have been justified in emptying a mag into her had she done anything other than fully comply with the given instructions.
This is a story of everyone doing the right thing, other than this idiotic girl. She's oh so lucky to be alive. Sad, she probably doesn't even realize just how stupid or lucky she has been. I can only guess someone this dumb got into MIT because they are good at exercising on their back.
She needs a month in jail, or more, to remind her the seriousness of the situation; and to remind others how stupid this idea was. It would be nice if MIT kicks her out of school too.
Re:Really not that bad
on
Lair Review
·
· Score: 5, Funny
Who cares if he was right or not, he was being a prick and created a scene.
I agree! Pricks don't deserve any protection under the law, even if he was forced to be a prick in reaction to a poorly conceived, commonly accepted practice which is annoying and abusive to start. Hopefully next time the cops will just shoot him so you'll be even happier.
See, that's why ala carte is stupid, while those channels might be popular with slashdot, they are massively unpopular with the public at large.
Then again, many channels that are never watches are also included in the rate. So while a single channel may go up, it is likely offset by not having the other 90 channels we never watch. Besides, ala carte does not mean packages can not be offered. Which in turn means, low priced channel packages. Rather, it likely means real channel packages which people will actually watch while paying a reasonable price. It is not unreasonable to expect a "geek package", which bundles the typical channels most every slashdot reader watches. If you want something beyond, pay $10 for the other 10 channels which interest you.
So rather than the geek population, which is actually fairly large, being forced to subsidize all the sports, soap, and other worthless channels, you can actually pay for the channels you want while still paying less in general. Some of the most expensive channels, by far, are the sports channels.
I see. I could have been more clear where I was coming from. I changed gears from one quote to the next in my post. I can understand how I lost you there.
The article discusses the rise of Linux as an OEM OS choice. You are talking about it as a developer platform after retail sale.
Actually I'm not. Believe it or not, applications must be developed and tested on the platform before its ever sold to the general population. Applications include things like dialing, menus, phone books, hot syncing, etc. The fact additional applications can be developed after the sale by end users is icing which helps increase the appeal of the device to a subset of end users.
Notice that I didn't compare Linux's latency to Symbian.
I hate to burst your bubble but Linux typically has lower latency than most other commercial RT OSs. Linux in no way, shape, or form, is considered a high latency beast, save only on the desktop, and that's because it is geared toward throughput, not low latency; which in turn explains why Linux typically stomps on Windows for throughput.
I've not done any phone development but I do RT development. If are experiencing latency issues, I suggest it may be platform specific issues with the kernel port or framework/application level issues which are causing your issues. Linux, in of it self, should not be the cause of any user perceptible latency issues. Which is why I pointed you toward much more likely causes than the kernel.
I'm not confused, I'm pissed! The Air Force apparently had solar powered iPod shuffles way back in the 1970s while the rest of us had to wait until 2005, and ours aren't even solar powered!
Interestingly enough, the Air Force's version of the iPod even came complete with its own form of DRM known as Selective Availability.
Not to mention it's very doubtful a tiny reactor would be able to have enough velocity to create a crater anywhere near that size. We've had lots and lots of debris fall back to earth...any large enough to worry about are monitored. The rest, wouldn't leave anything near that size.
But before that happened, IIRC, SCO's entire VAR channel gave them the finger because SCO refused to do anything to help them remain loyal. As a result, almost everyone one of them went to IBM or Linux; mostly to Linux. Long story short, SCO decided they would not support their sales, support, and consulting channel...and are now surprised they have no business as a result. SCO has no one to blame but SCO.
Hell, SCO's Nonstop Clustering (NSC) product sucks...it doesn't work worth crap. A single node failure can result in wiping/crashing the ENTIRE cluster. After which a re-installation on every node in the cluster is required. I think Compaq/HP got tired of dealing with this loser technology and started distancing themselves from it. I don't recall who actually did the development on that product, Compaq/HP or SCO.
To make matters worse, SCO is a real nightmare to support. AIX, OSF (Dec Unix), HPUX, Linux, so on, are all so easy in comparison. All together, it's almost impossible to have anything good as a result of using SCO (no support (lost their VARs), limited applications (people stopped developing on SCO because the platform sucks for developers), no real cluster solution (NSC) , contrary to best efforts by marketing. So what's left? Only a dope wouldn't move on to a better platform.
A keypress takes a significantly longer time to process on a Linux phone than on, say, a BREW phone or an MS Smartphone.
Sorry, I forgot to add this to my previous post. My Razor has one of the slowest interfaces I've ever seen on a phone, including phones I had five plus years ago. Button presses are often dropped. The user interface is horrible, kludgie, and beyond snail-slow. IIRC, my Razor is running Symbian. My point being, crappy user interfaces which create high latency key presses (or worst of all, dropped key presses which are common on my phone) is certainly not a Linux platform exclusive.
In other words, poor software design is a much larger issue for low latency than is the target platform. No matter what, you must have good developers for the platform or you'll wind up with a Razor.
Each OS has its benefits and tradeoffs. Linux's benefits are code "ownership" and full source access, not to mention a well-known API and a large pool of developers.
I'm not sure if you're including this in your,"large pool of developers", comment but, these days making the phone developer accessible after sale is starting to garner a fair bit of interest. In this regard, Linux can't be touched.
The major tradeoff that I've seen is the enormous latency in normal usage. A keypress takes a sigificantly longer time to process on a Linux phone than on, say, a BREW phone or an MS Smartphone.
This has every indication of a poor implementation rather than than any OS specific issues. Seems many people coming from the Unix/Linux world don't seem to understand you have a new set of design challenges to address; rather they design Unix philosophy-style which is not a good match for something like a cellphone. As a result, people are building processes which abstract an API, which in turn has another process talking to the API process which in turn, may or may not talk directly to the hardware. On such low resource units like cellphones, this means a high latency design. So I argue this is a developer design issue and has nothing to do with Linux on cell phones.
As more developers understand the new platform requires a new design approach, things will continue to improve. I believe for now you're simply seeing the growing pains of a new found, widely available platform among a young developer base who don't know better.
This is the compiler project I get excited about. Hopefully its progress will continue rapidly advancing. From what I understand, unlike GCC and PCC, extending llvm is straight forward, much easier to understand, and just code code rather than decades of retrofit as is GCC.
Take that with a grain of salt as this is not a first hand account.
In other words, it's a problem if you use anti-virus software. Use of anti-virus software which hooks system calls is actually creating an attack vector.
Right, but the original topic was for video, not patches. Sure, multicast is good for lots of things, and your patch example squarely falls under the rule of thumb I provided...but patches is not the real topic. The topic at hand is the ideal situation to not use multicast.
I agree, in this day and age, not having a plug to remove the GIL is beyond stupid.
It is worth pointing out that the situation isn't as bad as you imply as multi-core support most definitely has not been removed. Threading works great when python is I/O bound. Anytime python is outside of the interpretor handling an I/O operation, the GIL is released and allows another thread to execute. Threads which are executing inside the interpretor, continue to run regardless of the GIL's state. CPU bound tasks, on the other hand, essentially means python is single threaded unless your work is being done outside of the interpretor, which likely means there is no point in writing it in python.
To add insult to injury, python's process model sucks so if you want to go the fork model, things which should be easy in a high level language like python are as much a pain as they are in C, or almost so. Thus ultimately means if I have a need to take advantage of multiple cores and CPU bound, you're probably better off writing it in C/C++ than python. If on the other hand, I'm IO bound, and threading is desired, python is still attractive. In fact, python is very attractive for network servers.
So yes, the GIL is brain dead in this day and age, and will continue to become even dumber as days roll by, but threading + multi-core is not completely without merit in python.
Especially when someone points to the idiots from Redmondia (and other places) that they should stop reinventing multicast again and again.
Multicast makes no sense here, no sense at all. Multicast makes sense when everyone wants to see the same data at exactly the same time (e.g. video conference). For sharing of video clips, this would actually waste a huge chunk of bandwidth.
What you're proposing means the first person to watch the video gets to watch the video. Most someone wants to start watching it 10 seconds later and they miss the intro. Now another person starts watching it and they only get to see the end of the video clip. So now the second two people want to see the whole thing so the second person, starts again. The third person starts watching 10 seconds late. Now the first person (originally the second person) sees the whole video but the third person missed out on it...so now he starts again. Ultimately you created the perfect scheme to both waste bandwidth and really piss people off.
Well, those same people have admitted that plugable schedulers are not a good idea outside of scheduler development and research. Since maybe a dozen people need/want to do that, the overhead imposed simply didn't make sense.
Well damn. That's just... embarassing. Why's everyone using linux if it sucks so much?
Take his comments with a grain of salt. You can safely and completely ignore his comments about worst case latency because they are meaningless. In the Linux kernel, worst case latency almost always is caused by device drivers. Besides, most people have no idea how to properly measure worst case latency...and the measurement method may not reflect a real world workload in any meaningful way.
Depending on the devices you have, using otherwise identical hardware, worst case latency can vary based on an order of magnitude and the workload at hand. This is why realtime Linux vendors won't provide a guaranteed, worst case latency. Which is to say, they have no idea what your hardware will be so they don't know. Despite this, making some assumptions, worst case latency with good hardware and proper device drivers and reasonable CPU will usually be measured in single to double digit ms. Anything outside of this is enough to make one question the method of measurement, the workload use, and/or the machine/hardware specs involved.
I don't think that's really fair. Average these days actually has a large spread. Average web user? Average game player? Average video watcher? Average musician? Averaging what? And that's the point of the CFS. Each of those users have different expectations and each reflect a different type of scheduler workload. The old scheduler has lots and lots of code to handle various performance problems for corner cases for each type of "average user" depicted above. This in turn means the code is hard to read, hard to understand, and even harder to maintain. Worse, some code which help some corner cases actually make things worse for others. This in turn means more special case coding and even more complex testing.
The CFS is designed to simplify most everything the O(1) schedule does without tons of complex heuristics and special code to address various corner cases. In other words, in stead of trying to guess what you really want, the CFS simply tries to be as fair as possible for everyone, thusly ensuring many categories of corner cases are simply no longer an issue with the CFS.
This does not mean CFS is always better than O(1), but early results indicate they are traveling down a good road. In fact, the last round of patches I read about, actually establish CFS ~12% faster then the old O(1) schedule. Of course, it's yet to be seen how well it will be received and how quickly it will prove it self with a large user base. The devil is in the details with schedulers and sometimes real world user workloads don't reflect anything which has been tested/validating during development.
Nonetheless, development on CFS continues and it certainly is providing hope it will be smaller, faster, provide lower latency, be easier to maintain, and address a wider range of workloads, including many corner cases, without requiring complex code to track and analyze heuristics.
Long story short, yes, if all goes well, even the average user may notice an improvement depending on the particulars of their workload. Wouldn't you notice a more responsive desktop?;)
Slashdot Mirror
Sure, she was dumb for wearing the board, but banned for good from airports?
People willfully disturbing public transportation should consider alternate means for transport. The concept is not hard to understand nor would the reasons be difficult to deduce. There is a reason why it is a federal crime to make jokes about bombs at airports. Not only did she joke but she manufactured an actual device which she used to perpetrate her federal crime. It doesn't sound she has any business to be in an airport period, let alone in a time of war. She actually sounds like the perfect candidate to be banned.
That is unprofessional and boarder line illegal.
That is 100% incorrect. Airports are federally protected zones where lethal threat had been authorized. It would have been a fully legal to simply shoot her with a fully automatic weapon at the first hint of non-compliance.
A smart lawyer will do back flips to do everything possible to ensure she doesn't get jail time. It's likely she'll get banned from airports and/or aviation carriers.
I hate to say it, but you seem to be completely out of touch with reality. You need to go pick up a news paper and read what has been going on in the world for the last couple of years. Once you're up to speed with the rest of the adults, you'll understand why she is oh so lucky to be alive to talk about her stupidity.
Read my other comment. Hopefully it will put things into a more realistic perspective than you currently have.
disagree
I couldn't agree more. It's obvious she intended the device to be perceived as an explosive device. The facts we have:
Odd shirt with improvised electronics on it - detonator anyone?
Putty (play-doh) like substance in hand - explosives anyone? She couldn't explain why she had it.
Unresponsive to initial questions about her device by airport authorities
We ARE at war
Thousands have been murdered by people wearing this category of attire in the last year alone
So we have a stupid girl carrying what appears to be an explosive device while ignoring authority. She should have been shot to make sure this type of stupidity can't bread. She's lucky. IMO, any officer would have been justified in emptying a mag into her had she done anything other than fully comply with the given instructions.
This is a story of everyone doing the right thing, other than this idiotic girl. She's oh so lucky to be alive. Sad, she probably doesn't even realize just how stupid or lucky she has been. I can only guess someone this dumb got into MIT because they are good at exercising on their back.
She needs a month in jail, or more, to remind her the seriousness of the situation; and to remind others how stupid this idea was. It would be nice if MIT kicks her out of school too.
Behold! The Riders of Ron!
Sounds like a prison title to me.
Who cares if he was right or not, he was being a prick and created a scene.
I agree! Pricks don't deserve any protection under the law, even if he was forced to be a prick in reaction to a poorly conceived, commonly accepted practice which is annoying and abusive to start. Hopefully next time the cops will just shoot him so you'll be even happier.
Sarcasm off
See, that's why ala carte is stupid, while those channels might be popular with slashdot, they are massively unpopular with the public at large.
Then again, many channels that are never watches are also included in the rate. So while a single channel may go up, it is likely offset by not having the other 90 channels we never watch. Besides, ala carte does not mean packages can not be offered. Which in turn means, low priced channel packages. Rather, it likely means real channel packages which people will actually watch while paying a reasonable price. It is not unreasonable to expect a "geek package", which bundles the typical channels most every slashdot reader watches. If you want something beyond, pay $10 for the other 10 channels which interest you.
So rather than the geek population, which is actually fairly large, being forced to subsidize all the sports, soap, and other worthless channels, you can actually pay for the channels you want while still paying less in general. Some of the most expensive channels, by far, are the sports channels.
I see. I could have been more clear where I was coming from. I changed gears from one quote to the next in my post. I can understand how I lost you there.
The article discusses the rise of Linux as an OEM OS choice. You are talking about it as a developer platform after retail sale.
Actually I'm not. Believe it or not, applications must be developed and tested on the platform before its ever sold to the general population. Applications include things like dialing, menus, phone books, hot syncing, etc. The fact additional applications can be developed after the sale by end users is icing which helps increase the appeal of the device to a subset of end users.
Notice that I didn't compare Linux's latency to Symbian.
I hate to burst your bubble but Linux typically has lower latency than most other commercial RT OSs. Linux in no way, shape, or form, is considered a high latency beast, save only on the desktop, and that's because it is geared toward throughput, not low latency; which in turn explains why Linux typically stomps on Windows for throughput.
I've not done any phone development but I do RT development. If are experiencing latency issues, I suggest it may be platform specific issues with the kernel port or framework/application level issues which are causing your issues. Linux, in of it self, should not be the cause of any user perceptible latency issues. Which is why I pointed you toward much more likely causes than the kernel.
I'm not confused, I'm pissed! The Air Force apparently had solar powered iPod shuffles way back in the 1970s while the rest of us had to wait until 2005, and ours aren't even solar powered!
Interestingly enough, the Air Force's version of the iPod even came complete with its own form of DRM known as Selective Availability.
Not to mention it's very doubtful a tiny reactor would be able to have enough velocity to create a crater anywhere near that size. We've had lots and lots of debris fall back to earth...any large enough to worry about are monitored. The rest, wouldn't leave anything near that size.
They were a Linux distributor.
But before that happened, IIRC, SCO's entire VAR channel gave them the finger because SCO refused to do anything to help them remain loyal. As a result, almost everyone one of them went to IBM or Linux; mostly to Linux. Long story short, SCO decided they would not support their sales, support, and consulting channel...and are now surprised they have no business as a result. SCO has no one to blame but SCO.
Hell, SCO's Nonstop Clustering (NSC) product sucks...it doesn't work worth crap. A single node failure can result in wiping/crashing the ENTIRE cluster. After which a re-installation on every node in the cluster is required. I think Compaq/HP got tired of dealing with this loser technology and started distancing themselves from it. I don't recall who actually did the development on that product, Compaq/HP or SCO.
To make matters worse, SCO is a real nightmare to support. AIX, OSF (Dec Unix), HPUX, Linux, so on, are all so easy in comparison. All together, it's almost impossible to have anything good as a result of using SCO (no support (lost their VARs), limited applications (people stopped developing on SCO because the platform sucks for developers), no real cluster solution (NSC) , contrary to best efforts by marketing. So what's left? Only a dope wouldn't move on to a better platform.
A keypress takes a significantly longer time to process on a Linux phone than on, say, a BREW phone or an MS Smartphone.
Sorry, I forgot to add this to my previous post. My Razor has one of the slowest interfaces I've ever seen on a phone, including phones I had five plus years ago. Button presses are often dropped. The user interface is horrible, kludgie, and beyond snail-slow. IIRC, my Razor is running Symbian. My point being, crappy user interfaces which create high latency key presses (or worst of all, dropped key presses which are common on my phone) is certainly not a Linux platform exclusive.
In other words, poor software design is a much larger issue for low latency than is the target platform. No matter what, you must have good developers for the platform or you'll wind up with a Razor.
Each OS has its benefits and tradeoffs. Linux's benefits are code "ownership" and full source access, not to mention a well-known API and a large pool of developers.
,"large pool of developers", comment but, these days making the phone developer accessible after sale is starting to garner a fair bit of interest. In this regard, Linux can't be touched.
I'm not sure if you're including this in your
The major tradeoff that I've seen is the enormous latency in normal usage. A keypress takes a sigificantly longer time to process on a Linux phone than on, say, a BREW phone or an MS Smartphone.
This has every indication of a poor implementation rather than than any OS specific issues. Seems many people coming from the Unix/Linux world don't seem to understand you have a new set of design challenges to address; rather they design Unix philosophy-style which is not a good match for something like a cellphone. As a result, people are building processes which abstract an API, which in turn has another process talking to the API process which in turn, may or may not talk directly to the hardware. On such low resource units like cellphones, this means a high latency design. So I argue this is a developer design issue and has nothing to do with Linux on cell phones.
As more developers understand the new platform requires a new design approach, things will continue to improve. I believe for now you're simply seeing the growing pains of a new found, widely available platform among a young developer base who don't know better.
Unofficially there are rumblings of a December/January release.
This is the compiler project I get excited about. Hopefully its progress will continue rapidly advancing. From what I understand, unlike GCC and PCC, extending llvm is straight forward, much easier to understand, and just code code rather than decades of retrofit as is GCC.
Take that with a grain of salt as this is not a first hand account.
Sounds like we're on the same page. Death to Python. Long live Python. ;)
Left field. You. Go back and read the thread. Sheshh...
In other words, it's a problem if you use anti-virus software. Use of anti-virus software which hooks system calls is actually creating an attack vector.
Right, but the original topic was for video, not patches. Sure, multicast is good for lots of things, and your patch example squarely falls under the rule of thumb I provided...but patches is not the real topic. The topic at hand is the ideal situation to not use multicast.
I agree, in this day and age, not having a plug to remove the GIL is beyond stupid.
It is worth pointing out that the situation isn't as bad as you imply as multi-core support most definitely has not been removed. Threading works great when python is I/O bound. Anytime python is outside of the interpretor handling an I/O operation, the GIL is released and allows another thread to execute. Threads which are executing inside the interpretor, continue to run regardless of the GIL's state. CPU bound tasks, on the other hand, essentially means python is single threaded unless your work is being done outside of the interpretor, which likely means there is no point in writing it in python.
To add insult to injury, python's process model sucks so if you want to go the fork model, things which should be easy in a high level language like python are as much a pain as they are in C, or almost so. Thus ultimately means if I have a need to take advantage of multiple cores and CPU bound, you're probably better off writing it in C/C++ than python. If on the other hand, I'm IO bound, and threading is desired, python is still attractive. In fact, python is very attractive for network servers.
So yes, the GIL is brain dead in this day and age, and will continue to become even dumber as days roll by, but threading + multi-core is not completely without merit in python.
Especially when someone points to the idiots from Redmondia (and other places) that they should stop reinventing multicast again and again.
Multicast makes no sense here, no sense at all. Multicast makes sense when everyone wants to see the same data at exactly the same time (e.g. video conference). For sharing of video clips, this would actually waste a huge chunk of bandwidth.
What you're proposing means the first person to watch the video gets to watch the video. Most someone wants to start watching it 10 seconds later and they miss the intro. Now another person starts watching it and they only get to see the end of the video clip. So now the second two people want to see the whole thing so the second person, starts again. The third person starts watching 10 seconds late. Now the first person (originally the second person) sees the whole video but the third person missed out on it...so now he starts again. Ultimately you created the perfect scheme to both waste bandwidth and really piss people off.
So no, your solution is no solution at all.
Well, those same people have admitted that plugable schedulers are not a good idea outside of scheduler development and research. Since maybe a dozen people need/want to do that, the overhead imposed simply didn't make sense.
Well damn. That's just... embarassing. Why's everyone using linux if it sucks so much?
Take his comments with a grain of salt. You can safely and completely ignore his comments about worst case latency because they are meaningless. In the Linux kernel, worst case latency almost always is caused by device drivers. Besides, most people have no idea how to properly measure worst case latency...and the measurement method may not reflect a real world workload in any meaningful way.
Depending on the devices you have, using otherwise identical hardware, worst case latency can vary based on an order of magnitude and the workload at hand. This is why realtime Linux vendors won't provide a guaranteed, worst case latency. Which is to say, they have no idea what your hardware will be so they don't know. Despite this, making some assumptions, worst case latency with good hardware and proper device drivers and reasonable CPU will usually be measured in single to double digit ms. Anything outside of this is enough to make one question the method of measurement, the workload use, and/or the machine/hardware specs involved.
Average? Probably nothing.
;)
I don't think that's really fair. Average these days actually has a large spread. Average web user? Average game player? Average video watcher? Average musician? Averaging what? And that's the point of the CFS. Each of those users have different expectations and each reflect a different type of scheduler workload. The old scheduler has lots and lots of code to handle various performance problems for corner cases for each type of "average user" depicted above. This in turn means the code is hard to read, hard to understand, and even harder to maintain. Worse, some code which help some corner cases actually make things worse for others. This in turn means more special case coding and even more complex testing.
The CFS is designed to simplify most everything the O(1) schedule does without tons of complex heuristics and special code to address various corner cases. In other words, in stead of trying to guess what you really want, the CFS simply tries to be as fair as possible for everyone, thusly ensuring many categories of corner cases are simply no longer an issue with the CFS.
This does not mean CFS is always better than O(1), but early results indicate they are traveling down a good road. In fact, the last round of patches I read about, actually establish CFS ~12% faster then the old O(1) schedule. Of course, it's yet to be seen how well it will be received and how quickly it will prove it self with a large user base. The devil is in the details with schedulers and sometimes real world user workloads don't reflect anything which has been tested/validating during development.
Nonetheless, development on CFS continues and it certainly is providing hope it will be smaller, faster, provide lower latency, be easier to maintain, and address a wider range of workloads, including many corner cases, without requiring complex code to track and analyze heuristics.
Long story short, yes, if all goes well, even the average user may notice an improvement depending on the particulars of their workload. Wouldn't you notice a more responsive desktop?