She is represents the US as a prosecutor for the Supreme Court. Isn't she just doing her job?
Help me out here.
How is a public official (appointed, elected or otherwise) is "just doing her job" by coming out and publicly asking the courts to rule against the Constitution of the United States that the said public official took an oath to support?
Let me see - article VI, clause 3:
The Senators and Representatives before mentioned, and the Members of the several State Legislatures, and all executive and judicial Officers, both of the United States and of the several States, shall be bound by Oath or Affirmation, to support this Constitution; but no religious Test shall ever be required as a Qualification to any Office or public Trust under the United States.
In fact, the Constitution provides that if you violate that oath you have to be removed from office and can never be elected or serve any public office ever again (unless you can get 2/3 congress' support).
So, we have media and politicians up in arms about some guy who is sharing a couple of hundred songs (which nobody wants to buy or sell anymore) who has to pay $150,000 or some outrageous number per file, plus serve XX number of years in federal prison. But on the other hand we have elected public officials (or those appointed by elected public officials), who have taken the Oath of Affirmation to support the Constitution, taking 30% of all of our income in taxes, wasting our money on needless "projects", accumulating our national debt to where most of them can't even count anymore, "bailing out" their billionaire buddies, and most importantly, spend nearly every day of their elected/appointed life not only failing to support, but publicly renouncing and fighting against the very constitution that got them elected/appointed and that they took the oath to support?
And we just collectively say - oh, they are "just doing [their] job" and move on to more important stuff, like watching another episode of Kardiashians? +5 Insightful? This is why nothing will ever "change."
Wait a minute. Let's see who is trolling. From your previous post:
Why all this bullshit about being tainted for three months...
Got any proof of this "bullshit?" Because if you read the blog post, the cookie he was referring to (that was set for 3 months) was NOT from Bing, it was from the vendor's website, after accessing it from Bing. So, unless you know how to clear your cookies, that cookie will identify you as a "Bing customer" and potentially give you inflated prices during those 3 months. It could be even worse - there's nothing preventing a vendor from modifying its cookie every time you visit the website to extend it for 3 months (or any arbitrary period) from that date.
They may clean it up this time. But there probably are and will be more vendors doing this in the future without anybody having any clue, or getting any publicity. So, go ahead and call it "bullshit" but let's be clear on who's trolling here without any evidence to back up their claims.
There! He knows that clearing his cookies solves the problem. Why all this bullshit about being tainted for three months and being afraid to use their service to write a bloody blog post? Does he think the "oh noes teh bing cookeez" are going to trash his blog and kill his hamster too?
He knows, but most people have no idea what cookies are, much less how to "clear" them. So, after reading the article, now you know how most people are getting screwed by some vendors claiming they are getting the customers a discount going through Bing when in fact it could be costing them money.
Also, now that you know, and if you would consider getting Bing cashback at some point in the future, you'd be likely to check if the vendor was charging you more just because you arrived from Bing.
I wonder if Apple would honor their "warranty" if the computer smelled like shit and piss. Somehow, I think they'd play the "biohazard" card on that one too, and it would NOT be a story here, or anywhere else.
Besides, Apple sells their products in China and Asian countries where nearly 40% of population are smokers. Are there no warranties for Apple products in Asia?
I am not a smoker, but there are 2 claims made by pro-Apple, anti-smoking crowd:
1. It's a biohazard, like second hand smoking - no it's not, the computer is not emitting smoke. Wear gloves and face mask if it makes someone feel more comfortable and when necessary. You'd do that if you were dealing with a dusty computer too, or one containing human/pet hairs. You could call those biohazard too, but I guess going against smoking residue (since it contains the word "smoke") is more PC (no pun intended).
2. Tar residue causes extensive damage to components - this is debatable - does it cause more damage than dust and pet hair? Then put that in the warranty conditions and you're done. Anyway, Apple is not claiming this.
So, what are they claiming? Nothing, just whining, taking people's money and failing to uphold their part of the deal.
Any solution to sandbox each extension will just lead to eventual bloat.
How so? Whether the language does or doesn't support certain security features, they still have to implement the security within the browser. It's not a question of if, but how.
The problem is not the loosely typed language, it's that the API doesn't have a proper security model. One good way to implement it is to exactly sandbox each extension within their environment, only allow access to components/objects that are absolutely needed to run the extensions (but having no access to outside resources), and if additional access is required, present user with the security message and let the user decide whether to allow such access (either at install time, run time, selectively, allow user to grant for session/permanently, etc. - details can be adjusted as necessary).
It can't be that hard or "bloated" since many others are already doing this - Blackberry, Android, etc. - can't be too hard for a web browser.
'[Ben Wizner, a staff lawyer for the ACLU, said] screeners get a narrow exception to the Fourth Amendment, which prohibits unreasonable searches, strictly to keep weapons and explosives off planes, not to help police enforce other laws.'
So, how is this any different from:
Police get a narrow exception to the Fourth Amendment, which prohibits unreasonable searches, strictly to keep dangerous weapons and illegal drugs off streets/school surroundings/public parks/college campuses/subways/high rise buildings/etc.
Compression absolutely makes sense. Processing power is growing at a much, much greater rate than bandwidth.
Really? Do you have any facts to back up that statement, or is it just a wandering thought of the hour? Besides, just the growth rate of processing power vs. bandwidth does not give you the whole picture.
How about mix in other variables too: - battery life/efficiency - device size - underclocked CPUs
Overall "growth" of CPU processing power is not as great when you consider batteries are not making equivalent progress. And devices are getting smaller and thinner, meaning batteries and everything else will need to be smaller too.
The point is - without any concrete evidence your statement is at best a complete guess in the dark, and at worst AC trolling.
Ask yourself; what can be accomplished with a cookie that can't be accomplished using alternative mechanisms. Try thinking outside the box you've been in for the last 15 years.
So, what are you saying - all flash sites? SPDY protocol? AJAX apps? Because that's a very vague statement that means absolutely nothing.
Cookies are used to perform session management within a stateless protocol that is HTTP. Since the browser automatically passes headers with every request (cookies are part of those headers) that is how the server knows which user is returning from one page to the next. Sure there are other ways - embed session identifiers with every GET/POST request - i.e. you'll need to store those identifiers with your links and HTML form elements. However, that's a horrible idea - think of security/privacy implications when saving and sending web page content, or saving and sending links that contain an authenticated session identifiers embedded in them. It's just really stupid.
Compression has been optional and available for 10 years.
The client tells server it can decompress, and the server decides to send 'pre cached compressed' content, or compress dynamic content if it likes.
That's why I was saying it needs to _stay_ optional. But a later reply by the author says they would only be requiring compression on the header, so the point is moot.
eg. A 150kb FAQ would be quicker to show if it compresses to 30kb.
Are you just guessing, or do you have any supporting evidence? E.g. would it also be "quicker" if this was on an underpowered mobile device on a fast 3G network or wifi?
Now imagine if that same mobile device had to make not 1 but 5-10 connections, get compressed data and first have to decompress all of them before it's able to render and display a page. Would it be faster? Are there any tests to substantiate this claim?
As a server implementor I can tell you that I'd rather have 1 heavily used connection than 20 (that is a LOW estimate for the number of connections many sites make(!!!!!!!)). Server efficiency was one of my goals for the protocol, in fact!
Average of 20 seems a lot considering most browsers cache all static content (images/HTML/Javascript/CSS/XSLT/etc.). Also, keep-alive can bring that number down to even less.
That is also a very general statement to make. Again, maybe that's true in Google's case (I don't know), but HTTP keep-alive handles this already for most cases by giving you control of how long you want keep the resources hanging around for a connection, or free them up for another client, and it's all depending on your environment.
For example, I am visiting a shopping site, blog entry, SPDY documentation page, etc., on average visitors spend X seconds/minutes on a single page on that site. With HTTP keep alive you are in charge of how soon you want to free up the server resource, and make it available for the next visitor; with a single permanent connection, you are still holding on to the resource as long as the client is still there.
Now, with say 100 visitors per 1 [time interval] starting at point N, you'll need to keep those 100 connections open until at least N+X. Now add 100 more visitors arriving at N+1, then N+2, etc. until you reach X. That's how many connections you'll need to keep open on average.
What I am saying is that number of connections is not going to be optimal in most cases. Because you'll almost always want to free up the resources way prior to the average of X. In fact, let's take some numbers:
100 clients / 1 second X = 1 min 20 connections / client (took from your post) Avg connection = 0.5 sec (doesn't matter as it rolls into the value of X anyway) keep-alive = 0.5 sec (took from SPDY doc link)
With HTTP: 20 conns x 100 clients / sec = 2000 connections / sec (0.5 + 0.5) Avg num of connections = 2000 (no keep-alive on client) Avg num of connections = about 700 (w/keep-alive pipelining set to 4, default when enabled in Firefox)
Using SPDY: Avg num of connections = 100 clients x 60 secs = 6000 connections
This would only make sense for low enough values of X where client needs to be getting constant dynamic updates from the server - an extremely media-heavy website maybe? It would almost have to be badly designed. I'm not sure, but it's certainly interesting. I am just wondering what testing conditions were used to achieve the results mentioned on the linked SPDY page.
When we're talking about requiring compression, we're talking about compression over the headers only.
In any case, as someone who operates servers... I can't tell you how many times I've been angry at having to turn of compression for *EVERYONE* because some browser advertises supporting compression, but doesn't (which interacts badly with caches, etc. etc).
It's not all rosy as the short documentation page explains. While they are trying to maximize throughput and minimize latency, they are hurting other areas. 2 obvious downsides I see are:
1. Server would now have to keep holding the connection open to the client throughout the client's session, and also keep the associated resources in memory. While this may not be a problem for Google and their seemingly limitless processing powers, a Joe Webmaster will see their web server load average increase significantly. HTTP servers usually give you control over this with the HTTP keep-alive time and max connections/children settings. If the server is now required to keep the connections open it would spell more hardware for many/most websites;
2. Requiring compression seems silly to me. This would increase the processing power required on the web server (see above), and also on the client - think underpowered portable devices. It needs to stay optional - if the client and server both play and prefer compression, then they should do it; if not, then let them be; also keeping in mind that all images, video and other multimedia are already compressed - so adding compression to these items would increase the server/client load _and_ increase payload.
Sorry, but the patent does not describe or cover the access control system for users. It merely references the user account permissions as a base/reason for escalation.
The patent is about the interface used to escalate privileges in order to perform a task. The method of how it was determined that the user did not have access to the said task is irrelevant and is not covered by the patent.
In fact, the patent describes what kdesu and similar tools (using sudo) already do - i.e. something (some underlying system, script, program, etc. - it doesn't matter what/how) determines there is a need for privilege escalation for a specific task, and presents the user interface in order to do so. This patent covers that use interface.
I don't know that I'd use the test of patent language understanding to identify good technical job candidate, not for most jobs anyway, not yet anyway... unless every programmer will be required to be a patent lawyer too.... a selectable help graphic wherein responsive to receiving selection of the selectable help graphic...
Nobody knows what it means, but it's there to make it confusing and sound like they "invented" something.
And that would be almost-excusable, except for the brain-dead "open source is king" approach for updates: "The whole-thing's free anyway, why not just re-send the whole thing?" binary patches are pretty-much unheard of. Of course, sending the whole thing is really just a work-around because-
Package managers generally do NOT bother to detect when they are about to clobber or alter "the wrong file". When they do, they don't bother to keep a record of what they/would/ consider to be "the right file", making "merging" impossible and difference examination a guessing game. That doesn't even matter, because the first step in an "Upgrade" is usually to just completely remove the existing package, which means...
That's not true. Most dependencies are given for files and their specific versions. If the "to-be-installed" package offers a different version of the file/library that no longer satisfies the dependency, the package manager complains, and most of the time, tries to automatically find the best solution from available packages.
Multiple versions of a single package co-existing on the same base install is generally impossible. Which really makes you wonder what the hell a package manager/does/ manage.
It is possible and easily done. Package managers do not have any such restrictions and are able to happily manage multiple versions of the libraries quite well.
You want the bleeding-edge version of something? You just want to patch a broken package? That means you're not using the package manager, and that means you're on your own for everything. Either you build a/package/ for what you're doing on the side, or you don't get access to any of the supposed features. And anything that depends on what you're doing, you may as well just compile and track yourself- 'cause that's what you like doing, right?
Exactly right. Blame the packager, not the package manager. There's nothing in package managers that says you can't have KDE3 and KDE4 installed at the same time.
The short of it is: Package managers seem so fundamentally broken that giving them another task seems like a waste of time. They'll just be replaced by a better system eventually anyway, right? And then you'll need to do it all again.
This is like a person buying an off road kitted Unimog and then being upset that they can't get above 55mph when on the highway for long road trips. Then going out and buying a fast car and being pissed at the Unimog makers because it doesn't do what it wasn't built to do.
The Mac, from that analogy, being the "Unimog" and a Windows OS equipped PC being a "fast car" - from a user painandgreed - Steve Ballmer, is that you?
He's ruling on search warrants aimed at 3rd party ISPs; if someone does not keep their e-mail with the ISP, then his ruling doesn't apply to them.
So, if I have a USPS P.O. box, can government search it without a warrant? What if I check my P.O. box every 1-2 weeks or so? What if I have a hosted e-mail account that deletes old e-mails after 14 days? 30 days? 90 days? What if I have a voicemail box with my phone carrier that "hosts" my voice messages? Google hosts voicemail messages too. Either one of those could then be searched without a warrant.
And, so what if e-mail is in plain text and unencrypted - neither are letters in envelopes. An ISP opening user's e-mails and handing over specific messages is similar to USPS opening the physical mail and handing them over. Digital envelope vs. physical envelope. It's even called an "envelope" in the protocol and RFCs.
Furthermore, it only applies to those ISPs who actually tell the user, like Gmail does, that they will comply with government requests.
The issue is with government powers, not ISP's terms and conditions. ISP (GMail/Google) can read your e-mail and display ads based on its content if you want them to. They may want to say they play nice with the authorities too. However, that doesn't give an automatic power to the government to claim unchecked access to otherwise private data. The decision whether to turn over the e-mail messages, and whether so obtained data will be admissible in court, should not rest with your ISP (or their terms and conditions); just as it doesn't rest with the USPS office.
Slashdot Mirror
She is represents the US as a prosecutor for the Supreme Court. Isn't she just doing her job?
Help me out here.
How is a public official (appointed, elected or otherwise) is "just doing her job" by coming out and publicly asking the courts to rule against the Constitution of the United States that the said public official took an oath to support?
Let me see - article VI, clause 3:
The Senators and Representatives before mentioned, and the Members of the several State Legislatures, and all executive and judicial Officers, both of the United States and of the several States, shall be bound by Oath or Affirmation, to support this Constitution; but no religious Test shall ever be required as a Qualification to any Office or public Trust under the United States.
In fact, the Constitution provides that if you violate that oath you have to be removed from office and can never be elected or serve any public office ever again (unless you can get 2/3 congress' support).
So, we have media and politicians up in arms about some guy who is sharing a couple of hundred songs (which nobody wants to buy or sell anymore) who has to pay $150,000 or some outrageous number per file, plus serve XX number of years in federal prison. But on the other hand we have elected public officials (or those appointed by elected public officials), who have taken the Oath of Affirmation to support the Constitution, taking 30% of all of our income in taxes, wasting our money on needless "projects", accumulating our national debt to where most of them can't even count anymore, "bailing out" their billionaire buddies, and most importantly, spend nearly every day of their elected/appointed life not only failing to support, but publicly renouncing and fighting against the very constitution that got them elected/appointed and that they took the oath to support?
And we just collectively say - oh, they are "just doing [their] job" and move on to more important stuff, like watching another episode of Kardiashians? +5 Insightful? This is why nothing will ever "change."
What is completely unnecessary is:
1. Your condescending trollish post;
Wait a minute. Let's see who is trolling. From your previous post:
Why all this bullshit about being tainted for three months ...
Got any proof of this "bullshit?" Because if you read the blog post, the cookie he was referring to (that was set for 3 months) was NOT from Bing, it was from the vendor's website, after accessing it from Bing. So, unless you know how to clear your cookies, that cookie will identify you as a "Bing customer" and potentially give you inflated prices during those 3 months. It could be even worse - there's nothing preventing a vendor from modifying its cookie every time you visit the website to extend it for 3 months (or any arbitrary period) from that date.
They may clean it up this time. But there probably are and will be more vendors doing this in the future without anybody having any clue, or getting any publicity. So, go ahead and call it "bullshit" but let's be clear on who's trolling here without any evidence to back up their claims.
There! He knows that clearing his cookies solves the problem. Why all this bullshit about being tainted for three months and being afraid to use their service to write a bloody blog post? Does he think the "oh noes teh bing cookeez" are going to trash his blog and kill his hamster too?
He knows, but most people have no idea what cookies are, much less how to "clear" them. So, after reading the article, now you know how most people are getting screwed by some vendors claiming they are getting the customers a discount going through Bing when in fact it could be costing them money.
Also, now that you know, and if you would consider getting Bing cashback at some point in the future, you'd be likely to check if the vendor was charging you more just because you arrived from Bing.
Does everything have to be spelled out for you?
I'll take piss over smoke tar any day.
Every new parent cleans piss and crap up daily.
I wonder if Apple would honor their "warranty" if the computer smelled like shit and piss. Somehow, I think they'd play the "biohazard" card on that one too, and it would NOT be a story here, or anywhere else.
Besides, Apple sells their products in China and Asian countries where nearly 40% of population are smokers. Are there no warranties for Apple products in Asia?
I am not a smoker, but there are 2 claims made by pro-Apple, anti-smoking crowd:
1. It's a biohazard, like second hand smoking - no it's not, the computer is not emitting smoke. Wear gloves and face mask if it makes someone feel more comfortable and when necessary. You'd do that if you were dealing with a dusty computer too, or one containing human/pet hairs. You could call those biohazard too, but I guess going against smoking residue (since it contains the word "smoke") is more PC (no pun intended).
2. Tar residue causes extensive damage to components - this is debatable - does it cause more damage than dust and pet hair? Then put that in the warranty conditions and you're done. Anyway, Apple is not claiming this.
So, what are they claiming? Nothing, just whining, taking people's money and failing to uphold their part of the deal.
The problem is not with "every web page's content" that can be accessed via the extensions.
The problem is the security layer for the API that those extensions use. This is not rocket science as you make it out to be.
They could have put a chip in my brain that makes my think that I'm browsing securely but in fact I'm not!
So, you have hardwired your brain into your computer and are using it as a Firefox extension? This makes my head spin.
Any solution to sandbox each extension will just lead to eventual bloat.
How so? Whether the language does or doesn't support certain security features, they still have to implement the security within the browser. It's not a question of if, but how.
The problem is not the loosely typed language, it's that the API doesn't have a proper security model. One good way to implement it is to exactly sandbox each extension within their environment, only allow access to components/objects that are absolutely needed to run the extensions (but having no access to outside resources), and if additional access is required, present user with the security message and let the user decide whether to allow such access (either at install time, run time, selectively, allow user to grant for session/permanently, etc. - details can be adjusted as necessary).
It can't be that hard or "bloated" since many others are already doing this - Blackberry, Android, etc. - can't be too hard for a web browser.
Just one suggestion:
Try Arora. See if you still experience the same results as with other WebKit browsers.
'[Ben Wizner, a staff lawyer for the ACLU, said] screeners get a narrow exception to the Fourth Amendment, which prohibits unreasonable searches, strictly to keep weapons and explosives off planes, not to help police enforce other laws.'
So, how is this any different from:
Police get a narrow exception to the Fourth Amendment, which prohibits unreasonable searches, strictly to keep dangerous weapons and illegal drugs off streets/school surroundings/public parks/college campuses/subways/high rise buildings/etc.
Just wondering.
Compression absolutely makes sense. Processing power is growing at a much, much greater rate than bandwidth.
Really? Do you have any facts to back up that statement, or is it just a wandering thought of the hour? Besides, just the growth rate of processing power vs. bandwidth does not give you the whole picture.
How about mix in other variables too:
- battery life/efficiency
- device size
- underclocked CPUs
Overall "growth" of CPU processing power is not as great when you consider batteries are not making equivalent progress. And devices are getting smaller and thinner, meaning batteries and everything else will need to be smaller too.
The point is - without any concrete evidence your statement is at best a complete guess in the dark, and at worst AC trolling.
Ask yourself; what can be accomplished with a cookie that can't be accomplished using alternative mechanisms. Try thinking outside the box you've been in for the last 15 years.
So, what are you saying - all flash sites? SPDY protocol? AJAX apps? Because that's a very vague statement that means absolutely nothing.
Cookies are used to perform session management within a stateless protocol that is HTTP. Since the browser automatically passes headers with every request (cookies are part of those headers) that is how the server knows which user is returning from one page to the next. Sure there are other ways - embed session identifiers with every GET/POST request - i.e. you'll need to store those identifiers with your links and HTML form elements. However, that's a horrible idea - think of security/privacy implications when saving and sending web page content, or saving and sending links that contain an authenticated session identifiers embedded in them. It's just really stupid.
Compression has been optional and available for 10 years.
The client tells server it can decompress, and the server decides to send 'pre cached compressed' content, or compress dynamic content if it likes.
That's why I was saying it needs to _stay_ optional. But a later reply by the author says they would only be requiring compression on the header, so the point is moot.
eg. A 150kb FAQ would be quicker to show if it compresses to 30kb.
Are you just guessing, or do you have any supporting evidence? E.g. would it also be "quicker" if this was on an underpowered mobile device on a fast 3G network or wifi?
Now imagine if that same mobile device had to make not 1 but 5-10 connections, get compressed data and first have to decompress all of them before it's able to render and display a page. Would it be faster? Are there any tests to substantiate this claim?
As a server implementor I can tell you that I'd rather have 1 heavily used connection than 20 (that is a LOW estimate for the number of connections many sites make(!!!!!!!)). Server efficiency was one of my goals for the protocol, in fact!
Average of 20 seems a lot considering most browsers cache all static content (images/HTML/Javascript/CSS/XSLT/etc.). Also, keep-alive can bring that number down to even less.
That is also a very general statement to make. Again, maybe that's true in Google's case (I don't know), but HTTP keep-alive handles this already for most cases by giving you control of how long you want keep the resources hanging around for a connection, or free them up for another client, and it's all depending on your environment.
For example, I am visiting a shopping site, blog entry, SPDY documentation page, etc., on average visitors spend X seconds/minutes on a single page on that site. With HTTP keep alive you are in charge of how soon you want to free up the server resource, and make it available for the next visitor; with a single permanent connection, you are still holding on to the resource as long as the client is still there.
Now, with say 100 visitors per 1 [time interval] starting at point N, you'll need to keep those 100 connections open until at least N+X. Now add 100 more visitors arriving at N+1, then N+2, etc. until you reach X. That's how many connections you'll need to keep open on average.
What I am saying is that number of connections is not going to be optimal in most cases. Because you'll almost always want to free up the resources way prior to the average of X. In fact, let's take some numbers:
100 clients / 1 second
X = 1 min
20 connections / client (took from your post)
Avg connection = 0.5 sec (doesn't matter as it rolls into the value of X anyway)
keep-alive = 0.5 sec (took from SPDY doc link)
With HTTP:
20 conns x 100 clients / sec = 2000 connections / sec (0.5 + 0.5)
Avg num of connections = 2000 (no keep-alive on client)
Avg num of connections = about 700 (w/keep-alive pipelining set to 4, default when enabled in Firefox)
Using SPDY:
Avg num of connections = 100 clients x 60 secs = 6000 connections
This would only make sense for low enough values of X where client needs to be getting constant dynamic updates from the server - an extremely media-heavy website maybe? It would almost have to be badly designed. I'm not sure, but it's certainly interesting. I am just wondering what testing conditions were used to achieve the results mentioned on the linked SPDY page.
When we're talking about requiring compression, we're talking about compression over the headers only.
In any case, as someone who operates servers... I can't tell you how many times I've been angry at having to turn of compression for *EVERYONE* because some browser advertises supporting compression, but doesn't (which interacts badly with caches, etc. etc).
OK my bad on that one then.
That's called link pre-fetching and it has already been done.
It's not all rosy as the short documentation page explains. While they are trying to maximize throughput and minimize latency, they are hurting other areas. 2 obvious downsides I see are:
1. Server would now have to keep holding the connection open to the client throughout the client's session, and also keep the associated resources in memory. While this may not be a problem for Google and their seemingly limitless processing powers, a Joe Webmaster will see their web server load average increase significantly. HTTP servers usually give you control over this with the HTTP keep-alive time and max connections/children settings. If the server is now required to keep the connections open it would spell more hardware for many/most websites;
2. Requiring compression seems silly to me. This would increase the processing power required on the web server (see above), and also on the client - think underpowered portable devices. It needs to stay optional - if the client and server both play and prefer compression, then they should do it; if not, then let them be; also keeping in mind that all images, video and other multimedia are already compressed - so adding compression to these items would increase the server/client load _and_ increase payload.
Sorry, but the patent does not describe or cover the access control system for users. It merely references the user account permissions as a base/reason for escalation.
The patent is about the interface used to escalate privileges in order to perform a task. The method of how it was determined that the user did not have access to the said task is irrelevant and is not covered by the patent.
In fact, the patent describes what kdesu and similar tools (using sudo) already do - i.e. something (some underlying system, script, program, etc. - it doesn't matter what/how) determines there is a need for privilege escalation for a specific task, and presents the user interface in order to do so. This patent covers that use interface.
I don't know that I'd use the test of patent language understanding to identify good technical job candidate, not for most jobs anyway, not yet anyway... unless every programmer will be required to be a patent lawyer too. ... a selectable help graphic wherein responsive to receiving selection of the selectable help graphic ...
Nobody knows what it means, but it's there to make it confusing and sound like they "invented" something.
And that would be almost-excusable, except for the brain-dead "open source is king" approach for updates: "The whole-thing's free anyway, why not just re-send the whole thing?" binary patches are pretty-much unheard of. Of course, sending the whole thing is really just a work-around because-
SuSE has been doing binary deltas since Hector was a pup. Haven't others too?
Package managers generally do NOT bother to detect when they are about to clobber or alter "the wrong file". When they do, they don't bother to keep a record of what they /would/ consider to be "the right file", making "merging" impossible and difference examination a guessing game. That doesn't even matter, because the first step in an "Upgrade" is usually to just completely remove the existing package, which means...
That's not true. Most dependencies are given for files and their specific versions. If the "to-be-installed" package offers a different version of the file/library that no longer satisfies the dependency, the package manager complains, and most of the time, tries to automatically find the best solution from available packages.
Multiple versions of a single package co-existing on the same base install is generally impossible. Which really makes you wonder what the hell a package manager /does/ manage.
It is possible and easily done. Package managers do not have any such restrictions and are able to happily manage multiple versions of the libraries quite well.
You want the bleeding-edge version of something? You just want to patch a broken package? That means you're not using the package manager, and that means you're on your own for everything. Either you build a /package/ for what you're doing on the side, or you don't get access to any of the supposed features. And anything that depends on what you're doing, you may as well just compile and track yourself- 'cause that's what you like doing, right?
Exactly right. Blame the packager, not the package manager. There's nothing in package managers that says you can't have KDE3 and KDE4 installed at the same time.
The short of it is: Package managers seem so fundamentally broken that giving them another task seems like a waste of time. They'll just be replaced by a better system eventually anyway, right? And then you'll need to do it all again.
The closest to "right" I've seen is GoboLinux.
I don't see how they are "broken" at all.
Since this is /.
Car Analogy:
This is like a person buying an off road kitted Unimog and then being upset that they can't get above 55mph when on the highway for long road trips. Then going out and buying a fast car and being pissed at the Unimog makers because it doesn't do what it wasn't built to do.
The Mac, from that analogy, being the "Unimog" and a Windows OS equipped PC being a "fast car" - from a user painandgreed - Steve Ballmer, is that you?
He's ruling on search warrants aimed at 3rd party ISPs; if someone does not keep their e-mail with the ISP, then his ruling doesn't apply to them.
So, if I have a USPS P.O. box, can government search it without a warrant? What if I check my P.O. box every 1-2 weeks or so? What if I have a hosted e-mail account that deletes old e-mails after 14 days? 30 days? 90 days? What if I have a voicemail box with my phone carrier that "hosts" my voice messages? Google hosts voicemail messages too. Either one of those could then be searched without a warrant. And, so what if e-mail is in plain text and unencrypted - neither are letters in envelopes. An ISP opening user's e-mails and handing over specific messages is similar to USPS opening the physical mail and handing them over. Digital envelope vs. physical envelope. It's even called an "envelope" in the protocol and RFCs.
Furthermore, it only applies to those ISPs who actually tell the user, like Gmail does, that they will comply with government requests.
The issue is with government powers, not ISP's terms and conditions. ISP (GMail/Google) can read your e-mail and display ads based on its content if you want them to. They may want to say they play nice with the authorities too. However, that doesn't give an automatic power to the government to claim unchecked access to otherwise private data. The decision whether to turn over the e-mail messages, and whether so obtained data will be admissible in court, should not rest with your ISP (or their terms and conditions); just as it doesn't rest with the USPS office.