The issue is whether the use by British authorities of warrantless wiretaps of their own citizens was improper, even if it wasn't illegal for the NSA to warrantlessly wiretap UK citizens. If a government may not spy on its own citizens with a warrant, can it really get around that restriction just by having someone else do the spying for them?
It depends on the level of intelligence and the level of personality differences and the job.
I've definitely had situations before where I was willing to accept having to do a bit more hand-holding for an amiable co-worker than deal with someone who was moderately more competent but exponentially less possible to actually work with. It depends partly on how closely together we work. Intelligent jerks are good if you have a big chunk of well-defined work that you want implemented correctly--- send them off for a month or two to go write some KLOCs, and they come back later with some good work. It's important that they're competent (you want to just assume they can go off unsupervised and do it), and since you're not interacting much, not that important that they're impossible to work with.
But nice people are a lot better if you're working on something that needs a good amount of negotiation, compromise, subjective design choices, etc., and multiple people are going to be working closely together for some extended period of time.
The over-technical boss isn't only bad if he/she is clueless and frequently wrong--- one who's usually right and refuses to delegate anything to anyone can be a huge pain too, because they don't actually have the time to do every single person's job for them, but often try to micromanage as if they did. I mean, if they could actually do the details of everyone's project, why have employees under them at all? Sometimes a manager doesn't need to know the details, even if they're smart and knowledgeable enough that they could be brought up to speed if necessary.
I think it's at least partly driven by purposeful misuse of it in that way by people who either do or should know better--- whether because they want to make nuclear power seem scary, or just because they or their publishers want to sell books and push documentaries. One of the first major books on the subject uses the sensational title Three Mile Island: Thirty Minutes to Meltdown (1982), and its paperback cover has the even more sensational tagline, "The Untold Story--- Why It Happened And How It Can Happen Again". And even that looks like a sober scholarly analysis compared to subsequent books with subtitles like A Nuclear Omen for the Age of Terror.
Fortunately there are good books on the subject. But I suspect they don't sell as well.
There's usually more options, though. In a lot of cases, selling out isn't done to avoid going bankrupt, but just to make more profit than before--- the alternative would've been to be still-profitable, but smaller.
The article mentions Donegal and Cavan, which sandwich the western part of Northern Ireland. Donegal actually borders it to the north! Presumably if it could be seen in Donegal and Cavan, it could also be seen in Fermanagh?
The main argument I've seen is that it's a form of brainwashing, since young children are much more impressionable and susceptible to persuasion than older people are. Not specifically that it will force their parents to buy them a particular toy, but that it allows companies to try to mold future consumers to their liking.
Of course, even for adults advertising largely attempts to perform that sort of function---the idea that advertisements are good-faith attempts to inform potentially interested customers of a product they may like is rather quaint---but we generally feel that for adults, it's their own business to deal with it.
Yeah, that makes sense, but he seems to have taken it personally. It sounds like part of it stems from his feeling that Molnar unnecessarily wrote a replacement using his ideas and got credit for it, instead of helping out to turn one of Kolivas's fair-scheduling proposals into something that could be merged. Though from what I can tell Molnar's replies are all pretty friendly, and he seemed keen to provide appropriate credit.
He means something different by it--- that the scheduler should only look forward, not look back to per-process history in making its scheduling decisions. A common hack/heuristic to improve interactive performance is to boost the priority of processes that sleep a lot, since CPU-bound jobs sleep rarely, while interactive processes sleep a lot. Kolivas think that's a hack that obscures the real problems with interactive performance, and leads to unpredictable performance since it doesn't fix the underlying issues. So wants to design schedulers with good interactive performance that make decisions based purely on the current set of running processes and priorities, and the upcoming timeslices.
Took me a while to figure out what "forward looking" means in this context, since "forward-looking scheduler" doesn't seem to be common terminology, and I assumed he wasn't talking about his grand forward-looking vision for schedulerdom.
Based on some previous arguments he's had, it sounds like he opposes the common heuristic of upping interactive process priority by keeping track of how long processes sleep--- processes that sleep a lot are probably I/O bound, and should get a priority boost so they can run on the (less frequent than for CPU-bound processes) occasions when they're ready. Kolivas wants schedulers to be forward-looking in the sense that they decide how to schedule without looking at process run history, by looking purely at who's ready to run, available timeslices, priorities, etc.
My question is: is it in the kernel tree yet? Is this that 2.6.31 scheduler change I heard about earlier yesterday, or is it something Completely Different?
No, and probably won't ever be, though perhaps some ideas will be borrowed.
From his FAQ:
Are you looking at getting this into mainline?
LOL.
No really, are you?
LOL.
Really really, are you?
No. They would be crazy to use this scheduler anyway since it won't scale to their 4096 cpu machines. The only way is to rewrite it to work that way, or to have more than one scheduler in the kernel. I don't want to do the former, and mainline doesn't want to do the latter. Besides, apparently I'm a bad maintainer, which makes sense since for some reason I seem to want to have a career, a life, raise a family with kids and have hobbies, all of which have nothing to do with linux.
Can it be made to scale to 4096 CPUs?
Sure I guess you could run one runqueue per CPU package instead of a global one and so on, but I have no intention whatsoever at doing that because it will compromise the performance where *I* care.
The "bad maintainer" part is referring to bad blood over the adoption of Ingo Molnar's CFS over Kolivas's own RSDL, in particular at least one LKML poster suggesting that, all else being equal, it'd be better to merge Molnar's code, as he was more likely to be a reliable maintainer (Molnar's more tied into the workings of the mainline kernel development/merging/etc.).
There are entiresitesdevoted to ridiculing people and things found on Google Street View, which I assume is the kind of thing the complaints are about.
Even though for a large number of such things, using a mouse is actually faster than trying to concoct a cryptic Vim command that would have the same effect - that's because mouse was designed to solve certain tasks well, normally those involving dealing with selection and highlighting in 2D space, and thinking that keyboard can beat it at that with equal amount of training is simply delusional.
If you have to do operations only occasionally, I agree, it's easier to hunt in a menu for them. But it's really annoying when something you do relatively often requires clicking through two-deep menus every time you want to do it, as most graphical editors I've used seem to require.
Your rant makes a strange number of assumptions, and is weirdly defensive. I don't fix or otherwise administer servers for a living. I do, however, sometimes edit text files on computers that aren't physically located in the same room as me, from a number of devices, and for a variety of reasons. If you never need to edit a textfile located on another computer, that's fine, but don't pretend that it never is useful to anyone.
If you don't enjoy computers as a hobby, that's fine also. I think some hobbies other people have are inane wastes of time, like watching spectator sports or television series, but they're welcome to engage in them if they wish. Some of us, however, find technology interesting. I wonder, though, if you don't find technology interesting and have better things to do, why you're commenting on Slashdot.
I can't seem to google it up right now, but James Gosling wrote a very interesting article in 2002 about what is wrong with X11 and how he would have designed it from scratch if he could.
Are there really hordes of grassroots windows partisans? I can see people who use it because they find the alternatives worse or impractical, or even people who kind of like using it. But Enthusiasts? Is it the same sort of person who joins the College Republicans, and the Comcast Fan Club?
It did--- Slashdot's had a discussion system since the beginning (or at least very close to it). Pre-account-system comments aren't archived, though, it seems. You originally just entered a name and a comment and posted it, the way most blog comment sections still work today. Impersonation of well-known users was getting too common, though, so they introduced an account system in mid-1998, requiring that you either post as Anonymous Coward, or register an account to post as anyone else. It seems that the old stories only archive comments made after that switch, so the pre-mid-1998 comment threads are mostly in the bitbucket, except to the extent that the Wayback Machine got them.
I challenged him to show me something it could do that UltraEdit couldn't.
How about use it to edit a remote file over ssh, from an Android phone? Or do complex things without using the damn mouse? Or write macros in a usable macro language?
More generally, with commonly used software, some of us just don't care about the learning curve. With the tools I use daily, I don't even remember what the first hour of using them was like, because it was so many thousands of hours ago. I even find it interesting to learn about new ways of doing things, so I don't resent an hour or two of getting up to speed, even if I don't end up using the tool. I could see if I had to learn a new tool an hour before a deadline I'd be annoyed, but the simple solution to that is not to schedule your new-tool experimentation an hour before a deadline. =]
The issue isn't better key bindings, but the external controllability and API. Some proportion of us don't like the monolithic black-box approach, where the web browser is this big thing that does everything internally, and if you want to automate or customize anything, you have to do it via the browser's own internal scripting or customization hooks. Some of us like the idea of doing things at the WM and CLI scripting levels.
This is admittedly a sort of radical approach to that. It's possible there are in-between approaches that could be produced by having more traditional web browsers expose a more full-featured external API controllable from a CLI tool--- currently Firefox supports a very limited set of commands, basically the bare minimum to allow other programs to pass through links with "please open this URL in a new tab".
It's somewhat in between, like most Unix-style tools. It's usable as-is as a basic web browser (you can browse the web in it). It's also usable as a tool to build other things out of, but in the "app that other apps can talk to" sense, not the.NET or Java "a class library that you can link your apps to" sense.
It's partly a philosophy of general- versus special-purpose end-user programming, monolithic vs. interlocking-parts design, etc. No real right answers, but I see a space for this. In particular, those of us who like a particular window-manager approach, and heavily use its scripting, have long complained that the web is sort of a black box out of our reach--- either you make do with what you can do with wget or links or something, or you've got to relinquish control to Firefox. Sometimes you really do just want a one-window X11 app that renders a modern web page.
In addition, profit isn't fixed. When a tax is raised, some portion of it may come out of pockets of the corporation's customers, and some portion of it may reduce the corporation's profit margins, thereby coming out of the pockets of the corporation's stockholders. It's usually a mix of the two; which place most of the money comes from depends on the particular market the corporation is in--- how much pricing power they have, how fat their profit margins were to begin with, what competitors they have, etc.
False. ONE transcontinental railroad (the first) was supported with free land from the Congress. The funding was entirely private, and all future railroads were done without government assistance.
That isn't true at all.
The U.S. government spent $10 million purchasing land from Mexico, the Gadsden Purchase, for the express reason of helping Southern Pacific complete the southerly-route transcontinental railroad. It also received land grants.
The northerly-route transcontinental railroad, Northern Pacific, also received quite a lot of land grants.
In total, the U.S. government subsidized the construction of railroads in the 2nd half of the 19th century by giving them title to one-tenth of the territory of the United States.
Slashdot Mirror
The issue is whether the use by British authorities of warrantless wiretaps of their own citizens was improper, even if it wasn't illegal for the NSA to warrantlessly wiretap UK citizens. If a government may not spy on its own citizens with a warrant, can it really get around that restriction just by having someone else do the spying for them?
It depends on the level of intelligence and the level of personality differences and the job.
I've definitely had situations before where I was willing to accept having to do a bit more hand-holding for an amiable co-worker than deal with someone who was moderately more competent but exponentially less possible to actually work with. It depends partly on how closely together we work. Intelligent jerks are good if you have a big chunk of well-defined work that you want implemented correctly--- send them off for a month or two to go write some KLOCs, and they come back later with some good work. It's important that they're competent (you want to just assume they can go off unsupervised and do it), and since you're not interacting much, not that important that they're impossible to work with.
But nice people are a lot better if you're working on something that needs a good amount of negotiation, compromise, subjective design choices, etc., and multiple people are going to be working closely together for some extended period of time.
The over-technical boss isn't only bad if he/she is clueless and frequently wrong--- one who's usually right and refuses to delegate anything to anyone can be a huge pain too, because they don't actually have the time to do every single person's job for them, but often try to micromanage as if they did. I mean, if they could actually do the details of everyone's project, why have employees under them at all? Sometimes a manager doesn't need to know the details, even if they're smart and knowledgeable enough that they could be brought up to speed if necessary.
tunak tunak tun, da da da
I'm pretty sure, "ignored the summary and read TFA" is actually the reverse of standard Slashdot practice!
I think it's at least partly driven by purposeful misuse of it in that way by people who either do or should know better--- whether because they want to make nuclear power seem scary, or just because they or their publishers want to sell books and push documentaries. One of the first major books on the subject uses the sensational title Three Mile Island: Thirty Minutes to Meltdown (1982), and its paperback cover has the even more sensational tagline, "The Untold Story--- Why It Happened And How It Can Happen Again". And even that looks like a sober scholarly analysis compared to subsequent books with subtitles like A Nuclear Omen for the Age of Terror.
Fortunately there are good books on the subject. But I suspect they don't sell as well.
There's usually more options, though. In a lot of cases, selling out isn't done to avoid going bankrupt, but just to make more profit than before--- the alternative would've been to be still-profitable, but smaller.
The article mentions Donegal and Cavan, which sandwich the western part of Northern Ireland. Donegal actually borders it to the north! Presumably if it could be seen in Donegal and Cavan, it could also be seen in Fermanagh?
The main argument I've seen is that it's a form of brainwashing, since young children are much more impressionable and susceptible to persuasion than older people are. Not specifically that it will force their parents to buy them a particular toy, but that it allows companies to try to mold future consumers to their liking.
Of course, even for adults advertising largely attempts to perform that sort of function---the idea that advertisements are good-faith attempts to inform potentially interested customers of a product they may like is rather quaint---but we generally feel that for adults, it's their own business to deal with it.
Yeah, that makes sense, but he seems to have taken it personally. It sounds like part of it stems from his feeling that Molnar unnecessarily wrote a replacement using his ideas and got credit for it, instead of helping out to turn one of Kolivas's fair-scheduling proposals into something that could be merged. Though from what I can tell Molnar's replies are all pretty friendly, and he seemed keen to provide appropriate credit.
He means something different by it--- that the scheduler should only look forward, not look back to per-process history in making its scheduling decisions. A common hack/heuristic to improve interactive performance is to boost the priority of processes that sleep a lot, since CPU-bound jobs sleep rarely, while interactive processes sleep a lot. Kolivas think that's a hack that obscures the real problems with interactive performance, and leads to unpredictable performance since it doesn't fix the underlying issues. So wants to design schedulers with good interactive performance that make decisions based purely on the current set of running processes and priorities, and the upcoming timeslices.
Took me a while to figure out what "forward looking" means in this context, since "forward-looking scheduler" doesn't seem to be common terminology, and I assumed he wasn't talking about his grand forward-looking vision for schedulerdom.
Based on some previous arguments he's had, it sounds like he opposes the common heuristic of upping interactive process priority by keeping track of how long processes sleep--- processes that sleep a lot are probably I/O bound, and should get a priority boost so they can run on the (less frequent than for CPU-bound processes) occasions when they're ready. Kolivas wants schedulers to be forward-looking in the sense that they decide how to schedule without looking at process run history, by looking purely at who's ready to run, available timeslices, priorities, etc.
No, and probably won't ever be, though perhaps some ideas will be borrowed.
From his FAQ:
The "bad maintainer" part is referring to bad blood over the adoption of Ingo Molnar's CFS over Kolivas's own RSDL, in particular at least one LKML poster suggesting that, all else being equal, it'd be better to merge Molnar's code, as he was more likely to be a reliable maintainer (Molnar's more tied into the workings of the mainline kernel development/merging/etc.).
There are entire sites devoted to ridiculing people and things found on Google Street View, which I assume is the kind of thing the complaints are about.
If you have to do operations only occasionally, I agree, it's easier to hunt in a menu for them. But it's really annoying when something you do relatively often requires clicking through two-deep menus every time you want to do it, as most graphical editors I've used seem to require.
Your rant makes a strange number of assumptions, and is weirdly defensive. I don't fix or otherwise administer servers for a living. I do, however, sometimes edit text files on computers that aren't physically located in the same room as me, from a number of devices, and for a variety of reasons. If you never need to edit a textfile located on another computer, that's fine, but don't pretend that it never is useful to anyone.
If you don't enjoy computers as a hobby, that's fine also. I think some hobbies other people have are inane wastes of time, like watching spectator sports or television series, but they're welcome to engage in them if they wish. Some of us, however, find technology interesting. I wonder, though, if you don't find technology interesting and have better things to do, why you're commenting on Slashdot.
Is this the one?
Are there really hordes of grassroots windows partisans? I can see people who use it because they find the alternatives worse or impractical, or even people who kind of like using it. But Enthusiasts? Is it the same sort of person who joins the College Republicans, and the Comcast Fan Club?
It did--- Slashdot's had a discussion system since the beginning (or at least very close to it). Pre-account-system comments aren't archived, though, it seems. You originally just entered a name and a comment and posted it, the way most blog comment sections still work today. Impersonation of well-known users was getting too common, though, so they introduced an account system in mid-1998, requiring that you either post as Anonymous Coward, or register an account to post as anyone else. It seems that the old stories only archive comments made after that switch, so the pre-mid-1998 comment threads are mostly in the bitbucket, except to the extent that the Wayback Machine got them.
How about use it to edit a remote file over ssh, from an Android phone? Or do complex things without using the damn mouse? Or write macros in a usable macro language?
More generally, with commonly used software, some of us just don't care about the learning curve. With the tools I use daily, I don't even remember what the first hour of using them was like, because it was so many thousands of hours ago. I even find it interesting to learn about new ways of doing things, so I don't resent an hour or two of getting up to speed, even if I don't end up using the tool. I could see if I had to learn a new tool an hour before a deadline I'd be annoyed, but the simple solution to that is not to schedule your new-tool experimentation an hour before a deadline. =]
The issue isn't better key bindings, but the external controllability and API. Some proportion of us don't like the monolithic black-box approach, where the web browser is this big thing that does everything internally, and if you want to automate or customize anything, you have to do it via the browser's own internal scripting or customization hooks. Some of us like the idea of doing things at the WM and CLI scripting levels.
This is admittedly a sort of radical approach to that. It's possible there are in-between approaches that could be produced by having more traditional web browsers expose a more full-featured external API controllable from a CLI tool--- currently Firefox supports a very limited set of commands, basically the bare minimum to allow other programs to pass through links with "please open this URL in a new tab".
It's somewhat in between, like most Unix-style tools. It's usable as-is as a basic web browser (you can browse the web in it). It's also usable as a tool to build other things out of, but in the "app that other apps can talk to" sense, not the .NET or Java "a class library that you can link your apps to" sense.
It's partly a philosophy of general- versus special-purpose end-user programming, monolithic vs. interlocking-parts design, etc. No real right answers, but I see a space for this. In particular, those of us who like a particular window-manager approach, and heavily use its scripting, have long complained that the web is sort of a black box out of our reach--- either you make do with what you can do with wget or links or something, or you've got to relinquish control to Firefox. Sometimes you really do just want a one-window X11 app that renders a modern web page.
Presumably gat marriage is the gangsta equivalent of the traditional shotgun wedding.
In addition, profit isn't fixed. When a tax is raised, some portion of it may come out of pockets of the corporation's customers, and some portion of it may reduce the corporation's profit margins, thereby coming out of the pockets of the corporation's stockholders. It's usually a mix of the two; which place most of the money comes from depends on the particular market the corporation is in--- how much pricing power they have, how fat their profit margins were to begin with, what competitors they have, etc.
That isn't true at all.
The U.S. government spent $10 million purchasing land from Mexico, the Gadsden Purchase, for the express reason of helping Southern Pacific complete the southerly-route transcontinental railroad. It also received land grants.
The northerly-route transcontinental railroad, Northern Pacific, also received quite a lot of land grants.
In total, the U.S. government subsidized the construction of railroads in the 2nd half of the 19th century by giving them title to one-tenth of the territory of the United States.