Re:Bet there still isn't a decent "Stop!" button
on
HTML V5 and XHTML V2
·
· Score: 2, Insightful
Can't do that. That's because often the website you visit is the one sending the 3rd party data.
Think webmail (yahoo, gmail etc), when you receive spam, your webmail provider is the one sending you the data.
Usually they will try to filter the content to make it safe. BUT as history shows it's not always 100%.
The W3C or browser maker might also make a new tag/feature that your filtering libraries aren't aware of (e.g. old sites with guestbooks that might not filter out the "latest and greatest stuff").
With my proposal, users can enable javascript+flash for stuff like youtube, and youtube can be more certain that the comments about the video will be treated as plain html by browsers that support the security tag. Stuff that slips through the filters would likely still be rendered inactive by those browsers.
Bet there still isn't a decent "Stop!" button
on
HTML V5 and XHTML V2
·
· Score: 5, Interesting
You have to hand it to the W3C, they keep supplying web designers with rope.
I've been trying to get them (and browser people) to include a security oriented tag to disable unwanted features.
Why such tags are needed:
Say you run a site (webmail, myspace (remember the worm?), bbs etc) that is displaying content from 3rd parties (adverts, spammers, attackers) to unknown browsers (with different parsing bugs/behaviour).
With such tags you can give hints to the browsers to disable unwanted stuff between the tags, so that even if your site's filtering is insufficient (doesn't account for a problem in a new tag, or the browser interprets things differently/incorrectly), a browser that supports the tag will know that stuff is disabled, and thus the exploit fails.
I'm suggesting something like:
<restricton lock="Random_hard_to_guess_string" except="java,safe-html"/> browser ignores features except for java and safe-html. unsafe content here, but rendered safely by browser <restrictoff lock="wrong_string"/> more unsafe content here but still rendered safely by browser <restrictoff lock="Random_hard_to_guess_string"/> all features re-enabled
safe-html = a subset of html that we can be confident that popular browsers can render without being exploited e.g. <em>, <p>).
It doesn't have to be exactly as I suggest - my main point is HTML needs more "stop/brake" tags, and not just "turn/go faster" tags.
Before anyone brings it up, YES we must still attempt to filter stuff out (use libraries etc), the proposed tags are to be a safety net. Defense in depth.
With this sort of tag a site can allow javascript etc for content directly produced by the site, whilst being more certain of disabling undesirable stuff on 3rd party content that's displayed together (webmail, comments, malware from exploited advert/partner sites).
Basically an app will announce what sort of template sandbox it would want to be run as, and a user will decide whether it's OK or not. If OK, the OS will enforce the sandbox.
If an app claims to be a "guest game/applet" AND requests that it be run likewise, it won't be able to do much.
Whereas if an app claims to be a "guest game/applet" but actually requests "Full System Privileges" (the OS/GUI should pop up the usual warnings) it should be a lot easier to educate people not to run that sort of stuff. "Fun Screensaver" requests "Full User privileges" e.g. rights to read/write your email, bookmarks, downloads, turn your microphone on, etc.
I think some people are already working on stuff like that. It's not easy to do, but I believe it is possible. Maybe Apple or Microsoft might be able to pull it off. Microsoft might not want to do it badly enough though.
"But I guess that biographies of fictional characters and detailed descriptions of Japanese cartoon episodes have much more important place on wikipedia."
I wouldn't say more important. A more accurate term would be more secure/permanent place.
There are typically far more rabid fans of japanese cartoons willing to wage a wikiwar, than there are rabid fans of math proofs.
Now add the fact that stuff can and does get deleted, and you'll see that a lot of stuff worth keeping could get deleted just because there aren't any defenders willing to fight the admins over it, whereas lots of other stuff will get kept - if deleted they'll just get readded one way or another - often by some other fan who naturally thinks it should be there.
If you remove the deletion feature, then pages won't persist just because of persistent people, they'll all be there. Then you can build something on top to pick the version of the page that's regarded as most authoritative by you (or a group whose perspective you decide to use).
You were the one confidently telling people that they can use debit cards and if stuff happens, they can call the bank up and in two days they'll get their money back, no fuss and trouble.
And now you imply I'm trying to be an asshole, when you can't even come up with any evidence backing your claims.
If things turn out not as rosy as you painted and people believed you, they might be rather "inconvenienced".
FWIW, I _am_ an asshole, I sometimes try not to be one, unfortunately I don't succeed often enough.
Oh well, take comfort that even if I'm not convinced by your arguments, the Mr Morriseys of Slashdot might be:).
AFAIK the NYSE doesn't run 24/7, and it only opens for a short time. So while it's not trivial, you can actually fix broken stuff after it closes, and you have quite a lot of time to do it.
Whereas if you have something very important that runs 24/7 you need a system which you can fix while it's running. These type of systems can be a fair bit more complex, so if you don't have good admins they could cause the system to have even more downtimes, negating all that clustering and redundant stuff.
Sorry, I'm having difficulty finding the 2 days or 48 hours you claimed before, in the PDF you linked to. I don't even see any promise on any time limits on when you'd get your money back, or when the Bank would credit it back to you in good faith. As mentioned earlier - the US banks are supposed to do that within 10 days under normal circumstances.
Even if what you claim is true it's still so hard to find I bet the UK bank staff themselves don't know of such a promise/law, so there's no guarantee in _practice_ you'd get your money back in 2 days. You might still have to do all that calling etc I mentioned earlier to convince them to credit your money back in a timely manner.
Quote: "The holiday did not materialise. So where does Mr Morrisey stand? With regard to the holiday, whether you are covered or not depends on the type of debit card you use."
Not very reassuring to me.
If it was a credit card, I would have more options. More money in account = more options. More money I could use to pay for help. Credit cards are even better than cash in such cases.
As it is you should only use debit cards as poor and risky substitutes for credit cards if banks refuse to give you a credit card and where cash and cheques aren't a decent option.
I don't think you'll be able to recharge cars at just any business in 10 minutes.
Petrol/gasoline has 34Mj/litre.
Assuming your high tech car only needs the equivalent of 30 litres (conservatively assuming greater efficiencies) for a full charge, that means _each_ charging station will have to provide 30 * 34 megajoules in 600 seconds = 1.7 megawatts ( about 15,500 amps at 110V).
Still better to do rapid bulk energy transfers with hydrocarbons.
The main benefit of the batteries for cars if they work as advertised is the durability. I'm not going to buy a car where I have to spend $$$$$ to change the batteries every 3 years - it's not economical or even environmentally friendly to do so,
The other possible benefit of such batteries in a hybrid/electric car is that regenerative braking can occur over a wider range of decelerations with less energy being wasted as heat. Since the batteries can take higher charge currents you don't have to dump as much excess energy for rapid braking. This makes the car more efficient. You could still use capacitors to do that, but this gives the engineers more options to think of:).
While bullets move too fast to dodge, guns being pointed by humans might not always move too fast to dodge. Just make sure you don't dodge into the bullet path;).
I agree though the question really hasn't been answered.
I definitely do believe that the brain can speed up processing in such situations, lots of people appear to make quick _correct_ decisions in often fairly complex and difficult situations. Of course sometimes just freezing up works well enough - the rest of the body can often cope being let down by the brain (and the ER helps:) ). Training can help reduce the freezing up.
I believe the brain maintains a model of the world to help it decide what best to do. It's no point for the brain to work on "current world prediction" so fast at nonimportant times. If there's nothing interesting happening while you walk from one place to another doing "bullet time" is counterproductive. Probably consumes more resources plus it'll be pretty boring and frustrating - like playing a video game 1 frame at a time;).
Where do you get your 48 hours figure from? Who guarantees it? Is it the law or it's just part of the "terms and conditions are subject to change" stuff.
"The financial institution must promptly investigate an error and resolve it within 45 days. For errors involving new accounts (opened in the last 30 days), POS transactions, and foreign transactions, the institution may take up to 90 days to investigate the error. However, if the financial institution takes longer than 10 business days to complete its investigation, generally it must put back into your account the amount in question while it finishes the investigation. For new accounts, the financial institution may take up to 20 business days to credit your account for the amount you think is in error."
"On lost or stolen credit cards, your loss is limited to $50 per card (see Lost or Stolen Credit Cards). On an EFT card, your liability for an unauthorized withdrawal can vary:
Your loss is limited to $50 if you notify the financial institution within two business days after learning of loss or theft of your card or code. But you could lose as much as $500 if you do not tell the card issuer within two business days after learning of loss or theft. If you do not report an unauthorized transfer that appears on your statement within 60 days after the statement is mailed to you, you risk unlimited loss on transfers made after the 60-day period. That means you could lose all the money in your account plus your maximum overdraft line of credit, if any."
It sure ain't rosy for debit cards in the US of A.
So, please post some evidence to back your statements. Post the relevant _authoritative_ links for UK if you prefer. I'm now curious on how great debit card protections are in the UK.
That's why credit cards are better than debit cards for cardholders.
With debit cards when stuff happens, the money is gone from YOUR account. You then spend a lot of time and resources trying to get the money back.
With credit cards when stuff happens, the money is gone from someone else's account. You then contact the card company and say "Nope, I didn't buy that".
See how much the banks and FTC etc care about those fraudulent debits? Yes they care, but obviously not that much.
But if you're a merchant when stuff happens with credit cards, ouch. Good luck getting money for the stuff you sold. Sometimes the chargebacks can happen months later.
Where do these guys get money from?
on
Flying Humans
·
· Score: 1
It's not that cheap to do this sort of stuff right? Equipment, practice, fees, travel and accomodation expenses etc.
The only "benefit" of UAC is it allows Microsoft to shift more blame to the users. Because it gets in the way so much that the users who need the most help will turn it off.
Expecting users to make those sort of decisions at that level is about as reasonable as asking Joe Sixpack to solve something akin to the "Halting Problem" without even being able to see the source code e.g. "Will letting this program run screw up my computer?".
I suggest something like this will be better: https://bugs.launchpad.net/ubuntu/+bug/156693
It's _hard_ to do, but I claim it is possible for things to be MUCH better than the crap that's UAC.
After X billions and how many years, what benefit does Vista really provide to users? The per app audio control is good, but I'm a tad underwhelmed... BTW linux sound stuff really sucks.
If your code is so crap and you can't seem to get better at it, maybe you should get a new job where you can do work which you are reasonably proud of. Do you really want to be like those CEOs who do a crap job and get paid for making everyone else suffer?
I'm definitely not the best coder out there, but wow there sure are plenty worse - the benefits of open source is you get to see how crap (or good) other people's code is compared to yours:).
I don't like some of the stuff I had to write in the style of someone else's code - fixes/changes to old (and often very crappy code). Sometimes you can only just make things less crappy - if you try to remove all the crappy bits you end up having to rewrite everything, but nobody will reward you for that and you'll get in trouble for anything they don't like.
The stuff I write from scratch for production usually has very few bugs. I don't churn out code rapidly like others, but my stuff tends to work and keep working. I have a fair bit of experience in IT security and breaking/abusing stuff, so I write stuff accordingly.
I'm also really lazy, so I'd rather get things right first or second go so that I can waste time on slashdot and other stuff:).
Typically the "problem reports" I get end up being due to something else.
Recent examples:
Someone thought there was a prob with one of my programs, so we looked, then got another colleague to look and conclusion was it was likely to be a bug in Linux, perl or hardware (in order of likelihood). Somehow after a restart of apache, Linux/netstat claimed that my program was listening on IPv6:::* port 80, and unless we're all wrong here there's no way my program would do that - the socket binds are all IPv4 only (pretty easy to check:) ) only done at the start and both the program and apache were running fine before. The program was started days before and was still running at the time apache was restarted (and failed to rebind to 80).
Then there was a reported problem with the dhcp server I wrote. I initially thought it was my bug. My dhcpd sends IP broadcasts in ethernet broadcast frames as replies to Vista (as default vista wants) which worked fine everywhere else (unlike some versions of ISC's dhcpd. Nyah!;) ). At some places Vista machines could not get an IP when behind some network devices. Turns out to get things working the dhcp server had to send an IP broadcast but ethernet unicast.
I thought, "oops my fault, should have done that from the start" (I actually did have a comment there wondering whether I should use unicast ethernet replies- seemed more efficient ), but after rereading the RFC2131 and doing some thinking (it's not explicit that broadcast = IP AND layer2 broadcast, but reasonable enough assumption right?), conclusion was the way I originally did stuff was RFC compliant, and it was the network device that was misbehaving - it should behave like a switch/hub and pass the layer 2 broadcast frames. So the fix will be a "configurable workaround" thingy. Easier to "fix" my dhcpd than to fix a few hundred network devices made by some other vendor.
Oh well side benefit is my dhcpd can now be configured to reduce dhcp broadcast traffic due to vista. I doubt we'll encounter that many vista machines though;).
As for the customer not always being right, well that's the company's fault, and fault of the person handling the customer.
The customer knows _vaguely_ what they want, you have to help them figure out what they really want. Take building a custom house as an example.
The Architect has to sit with the customers and say things like "If you want an olympic size pool, you can't have parking space for 4 SUVs unless you're willing to fork out a lot more money, and it'll take at least 3 months longer, and we'll probably do things this way".
Thing is most companies don't have people who 1) understand that, and 2) can actual
Now the trick is to know what things might likely be changed in the future and design things accordingly so that those bits can be more easily changed ( or not need to be changed at all - no changes needed to code- just set this config var:) ).
You could strike the offending clauses out, sign and send it back to them. If they still agree no prob then. Don't be surprised if most of the time the bosses etc don't care (it's just put in there by "Legal", and often from copying some "cookie cutter" doc).
I've had some even agree that its unfair - "Yeah that sucks, strike that out then".
There's one big limitation I find with Perl 5.8. It's slow. Don't get me wrong it's fast enough in many cases.
BUT if it was 20-30 times faster people would be able to use it for a lot more stuff where they'd otherwise have to resort to stuff that involves a lot more work:).
Parrot hasn't been very impressive, and ponie is dead anyway.
Yeah I know python is a bit faster and cleaner but so far it doesn't seem like a huge improvement.
I've looked at Lisp and I've come to the conclusion that:
Lisp is powerful for all the code you write, unfortunately you still have to write a lot of that code yourself.
In contrast Perl is powerful because of all the code you don't have to write.:)
Slashdot Mirror
Can't do that. That's because often the website you visit is the one sending the 3rd party data.
Think webmail (yahoo, gmail etc), when you receive spam, your webmail provider is the one sending you the data.
Usually they will try to filter the content to make it safe. BUT as history shows it's not always 100%.
The W3C or browser maker might also make a new tag/feature that your filtering libraries aren't aware of (e.g. old sites with guestbooks that might not filter out the "latest and greatest stuff").
With my proposal, users can enable javascript+flash for stuff like youtube, and youtube can be more certain that the comments about the video will be treated as plain html by browsers that support the security tag. Stuff that slips through the filters would likely still be rendered inactive by those browsers.
You have to hand it to the W3C, they keep supplying web designers with rope.
/> /> />
I've been trying to get them (and browser people) to include a security oriented tag to disable unwanted features.
Why such tags are needed:
Say you run a site (webmail, myspace (remember the worm?), bbs etc) that is displaying content from 3rd parties (adverts, spammers, attackers) to unknown browsers (with different parsing bugs/behaviour).
With such tags you can give hints to the browsers to disable unwanted stuff between the tags, so that even if your site's filtering is insufficient (doesn't account for a problem in a new tag, or the browser interprets things differently/incorrectly), a browser that supports the tag will know that stuff is disabled, and thus the exploit fails.
I'm suggesting something like:
<restricton lock="Random_hard_to_guess_string" except="java,safe-html"
browser ignores features except for java and safe-html.
unsafe content here, but rendered safely by browser
<restrictoff lock="wrong_string"
more unsafe content here but still rendered safely by browser
<restrictoff lock="Random_hard_to_guess_string"
all features re-enabled
safe-html = a subset of html that we can be confident that popular browsers can render without being exploited e.g. <em>, <p>).
It doesn't have to be exactly as I suggest - my main point is HTML needs more "stop/brake" tags, and not just "turn/go faster" tags.
Before anyone brings it up, YES we must still attempt to filter stuff out (use libraries etc), the proposed tags are to be a safety net. Defense in depth.
With this sort of tag a site can allow javascript etc for content directly produced by the site, whilst being more certain of disabling undesirable stuff on 3rd party content that's displayed together (webmail, comments, malware from exploited advert/partner sites).
I've proposed sandbox security templates:
https://bugs.launchpad.net/ubuntu/+bug/156693
Basically an app will announce what sort of template sandbox it would want to be run as, and a user will decide whether it's OK or not. If OK, the OS will enforce the sandbox.
If an app claims to be a "guest game/applet" AND requests that it be run likewise, it won't be able to do much.
Whereas if an app claims to be a "guest game/applet" but actually requests "Full System Privileges" (the OS/GUI should pop up the usual warnings) it should be a lot easier to educate people not to run that sort of stuff. "Fun Screensaver" requests "Full User privileges" e.g. rights to read/write your email, bookmarks, downloads, turn your microphone on, etc.
I think some people are already working on stuff like that. It's not easy to do, but I believe it is possible. Maybe Apple or Microsoft might be able to pull it off. Microsoft might not want to do it badly enough though.
What happened? The mathematicians proved that there was a trivial solution and then went away satisfied?
:).
As someone who did EE, I'm fine with using either j or i depending on the situation. Different strokes for different folks
"But I guess that biographies of fictional characters and detailed descriptions of Japanese cartoon episodes have much more important place on wikipedia."
I wouldn't say more important. A more accurate term would be more secure/permanent place.
There are typically far more rabid fans of japanese cartoons willing to wage a wikiwar, than there are rabid fans of math proofs.
Now add the fact that stuff can and does get deleted, and you'll see that a lot of stuff worth keeping could get deleted just because there aren't any defenders willing to fight the admins over it, whereas lots of other stuff will get kept - if deleted they'll just get readded one way or another - often by some other fan who naturally thinks it should be there.
If you remove the deletion feature, then pages won't persist just because of persistent people, they'll all be there. Then you can build something on top to pick the version of the page that's regarded as most authoritative by you (or a group whose perspective you decide to use).
"take a look at the whole Flash ecosystem"?
I'm sure a whole bunch of security researchers (and "security researchers") have done so and are rubbing their hands with glee.
Just look at where Adobe took PDF - from the early relatively safe years to the javascript ridden present.
You were the one confidently telling people that they can use debit cards and if stuff happens, they can call the bank up and in two days they'll get their money back, no fuss and trouble.
:).
And now you imply I'm trying to be an asshole, when you can't even come up with any evidence backing your claims.
If things turn out not as rosy as you painted and people believed you, they might be rather "inconvenienced".
FWIW, I _am_ an asshole, I sometimes try not to be one, unfortunately I don't succeed often enough.
Oh well, take comfort that even if I'm not convinced by your arguments, the Mr Morriseys of Slashdot might be
AFAIK the NYSE doesn't run 24/7, and it only opens for a short time. So while it's not trivial, you can actually fix broken stuff after it closes, and you have quite a lot of time to do it.
Whereas if you have something very important that runs 24/7 you need a system which you can fix while it's running. These type of systems can be a fair bit more complex, so if you don't have good admins they could cause the system to have even more downtimes, negating all that clustering and redundant stuff.
Sorry, I'm having difficulty finding the 2 days or 48 hours you claimed before, in the PDF you linked to. I don't even see any promise on any time limits on when you'd get your money back, or when the Bank would credit it back to you in good faith. As mentioned earlier - the US banks are supposed to do that within 10 days under normal circumstances.
Even if what you claim is true it's still so hard to find I bet the UK bank staff themselves don't know of such a promise/law, so there's no guarantee in _practice_ you'd get your money back in 2 days. You might still have to do all that calling etc I mentioned earlier to convince them to credit your money back in a timely manner.
As for the BBC (who aren't a bank or bank regulator), they also say stuff like this:
http://news.bbc.co.uk/1/hi/programmes/working_lunch/3957903.stm
Quote:
"The holiday did not materialise. So where does Mr Morrisey stand? With regard to the holiday, whether you are covered or not depends on the type of debit card you use."
Not very reassuring to me.
If it was a credit card, I would have more options. More money in account = more options. More money I could use to pay for help. Credit cards are even better than cash in such cases.
As it is you should only use debit cards as poor and risky substitutes for credit cards if banks refuse to give you a credit card and where cash and cheques aren't a decent option.
Nothing?
;).
Wow. You might qualify for the second round of sterilization then
I don't think you'll be able to recharge cars at just any business in 10 minutes.
:).
Petrol/gasoline has 34Mj/litre.
Assuming your high tech car only needs the equivalent of 30 litres (conservatively assuming greater efficiencies) for a full charge, that means _each_ charging station will have to provide 30 * 34 megajoules in 600 seconds = 1.7 megawatts ( about 15,500 amps at 110V).
Still better to do rapid bulk energy transfers with hydrocarbons.
The main benefit of the batteries for cars if they work as advertised is the durability. I'm not going to buy a car where I have to spend $$$$$ to change the batteries every 3 years - it's not economical or even environmentally friendly to do so,
The other possible benefit of such batteries in a hybrid/electric car is that regenerative braking can occur over a wider range of decelerations with less energy being wasted as heat. Since the batteries can take higher charge currents you don't have to dump as much excess energy for rapid braking. This makes the car more efficient. You could still use capacitors to do that, but this gives the engineers more options to think of
While bullets move too fast to dodge, guns being pointed by humans might not always move too fast to dodge. Just make sure you don't dodge into the bullet path ;).
:) ). Training can help reduce the freezing up.
;).
I agree though the question really hasn't been answered.
I definitely do believe that the brain can speed up processing in such situations, lots of people appear to make quick _correct_ decisions in often fairly complex and difficult situations. Of course sometimes just freezing up works well enough - the rest of the body can often cope being let down by the brain (and the ER helps
I believe the brain maintains a model of the world to help it decide what best to do. It's no point for the brain to work on "current world prediction" so fast at nonimportant times. If there's nothing interesting happening while you walk from one place to another doing "bullet time" is counterproductive. Probably consumes more resources plus it'll be pretty boring and frustrating - like playing a video game 1 frame at a time
Where do you get your 48 hours figure from? Who guarantees it? Is it the law or it's just part of the "terms and conditions are subject to change" stuff.
From: http://www.federalreserve.gov/pubs/consumerhdbk/electronic.htm
"The financial institution must promptly investigate an error and resolve it within 45 days. For errors involving new accounts (opened in the last 30 days), POS transactions, and foreign transactions, the institution may take up to 90 days to investigate the error. However, if the financial institution takes longer than 10 business days to complete its investigation, generally it must put back into your account the amount in question while it finishes the investigation. For new accounts, the financial institution may take up to 20 business days to credit your account for the amount you think is in error."
"On lost or stolen credit cards, your loss is limited to $50 per card (see Lost or Stolen Credit Cards). On an EFT card, your liability for an unauthorized withdrawal can vary:
Your loss is limited to $50 if you notify the financial institution within two business days after learning of loss or theft of your card or code.
But you could lose as much as $500 if you do not tell the card issuer within two business days after learning of loss or theft.
If you do not report an unauthorized transfer that appears on your statement within 60 days after the statement is mailed to you, you risk unlimited loss on transfers made after the 60-day period. That means you could lose all the money in your account plus your maximum overdraft line of credit, if any."
It sure ain't rosy for debit cards in the US of A.
So, please post some evidence to back your statements. Post the relevant _authoritative_ links for UK if you prefer. I'm now curious on how great debit card protections are in the UK.
With credit cards the money is still in your account while you "wait".
:).
With debit cards the money is gone while you _wait_.
Very big difference to me
"Alleged IOU" in somebody else's pocket vs my money in somebody else's pocket.
Maybe most people think that's practically the same thing, but I don't.
That's why credit cards are better than debit cards for cardholders.
With debit cards when stuff happens, the money is gone from YOUR account.
You then spend a lot of time and resources trying to get the money back.
With credit cards when stuff happens, the money is gone from someone else's account.
You then contact the card company and say "Nope, I didn't buy that".
See how much the banks and FTC etc care about those fraudulent debits? Yes they care, but obviously not that much.
But if you're a merchant when stuff happens with credit cards, ouch. Good luck getting money for the stuff you sold. Sometimes the chargebacks can happen months later.
It's not that cheap to do this sort of stuff right? Equipment, practice, fees, travel and accomodation expenses etc.
The worst fliers leave their traces on the contours :).
The one I heard is:
Odds of not surviving a hit-
AA = 25%
SAM = 50%
ground = 100%
Maybe it's all that pollution...
;).
And maybe Chernobyl helped
What security improvement?
The only "benefit" of UAC is it allows Microsoft to shift more blame to the users. Because it gets in the way so much that the users who need the most help will turn it off.
Expecting users to make those sort of decisions at that level is about as reasonable as asking Joe Sixpack to solve something akin to the "Halting Problem" without even being able to see the source code e.g. "Will letting this program run screw up my computer?".
I suggest something like this will be better:
https://bugs.launchpad.net/ubuntu/+bug/156693
It's _hard_ to do, but I claim it is possible for things to be MUCH better than the crap that's UAC.
After X billions and how many years, what benefit does Vista really provide to users? The per app audio control is good, but I'm a tad underwhelmed... BTW linux sound stuff really sucks.
If your code is so crap and you can't seem to get better at it, maybe you should get a new job where you can do work which you are reasonably proud of. Do you really want to be like those CEOs who do a crap job and get paid for making everyone else suffer?
:).
:).
:::* port 80, and unless we're all wrong here there's no way my program would do that - the socket binds are all IPv4 only (pretty easy to check :) ) only done at the start and both the program and apache were running fine before. The program was started days before and was still running at the time apache was restarted (and failed to rebind to 80).
;) ). At some places Vista machines could not get an IP when behind some network devices. Turns out to get things working the dhcp server had to send an IP broadcast but ethernet unicast.
;).
I'm definitely not the best coder out there, but wow there sure are plenty worse - the benefits of open source is you get to see how crap (or good) other people's code is compared to yours
I don't like some of the stuff I had to write in the style of someone else's code - fixes/changes to old (and often very crappy code). Sometimes you can only just make things less crappy - if you try to remove all the crappy bits you end up having to rewrite everything, but nobody will reward you for that and you'll get in trouble for anything they don't like.
The stuff I write from scratch for production usually has very few bugs. I don't churn out code rapidly like others, but my stuff tends to work and keep working. I have a fair bit of experience in IT security and breaking/abusing stuff, so I write stuff accordingly.
I'm also really lazy, so I'd rather get things right first or second go so that I can waste time on slashdot and other stuff
Typically the "problem reports" I get end up being due to something else.
Recent examples:
Someone thought there was a prob with one of my programs, so we looked, then got another colleague to look and conclusion was it was likely to be a bug in Linux, perl or hardware (in order of likelihood). Somehow after a restart of apache, Linux/netstat claimed that my program was listening on IPv6
Then there was a reported problem with the dhcp server I wrote. I initially thought it was my bug. My dhcpd sends IP broadcasts in ethernet broadcast frames as replies to Vista (as default vista wants) which worked fine everywhere else (unlike some versions of ISC's dhcpd. Nyah!
I thought, "oops my fault, should have done that from the start" (I actually did have a comment there wondering whether I should use unicast ethernet replies- seemed more efficient ), but after rereading the RFC2131 and doing some thinking (it's not explicit that broadcast = IP AND layer2 broadcast, but reasonable enough assumption right?), conclusion was the way I originally did stuff was RFC compliant, and it was the network device that was misbehaving - it should behave like a switch/hub and pass the layer 2 broadcast frames. So the fix will be a "configurable workaround" thingy. Easier to "fix" my dhcpd than to fix a few hundred network devices made by some other vendor.
Oh well side benefit is my dhcpd can now be configured to reduce dhcp broadcast traffic due to vista. I doubt we'll encounter that many vista machines though
As for the customer not always being right, well that's the company's fault, and fault of the person handling the customer.
The customer knows _vaguely_ what they want, you have to help them figure out what they really want. Take building a custom house as an example.
The Architect has to sit with the customers and say things like "If you want an olympic size pool, you can't have parking space for 4 SUVs unless you're willing to fork out a lot more money, and it'll take at least 3 months longer, and we'll probably do things this way".
Thing is most companies don't have people who 1) understand that, and 2) can actual
For me code is decision compression.
:) ).
Now the trick is to know what things might likely be changed in the future and design things accordingly so that those bits can be more easily changed ( or not need to be changed at all - no changes needed to code- just set this config var
"I commit my data to DVD overnight and archive on seagate drives. If they die, I get a replacement. By the time these 750gb drives"...
750GB = a lot of DVDs.
You could strike the offending clauses out, sign and send it back to them. If they still agree no prob then. Don't be surprised if most of the time the bosses etc don't care (it's just put in there by "Legal", and often from copying some "cookie cutter" doc).
I've had some even agree that its unfair - "Yeah that sucks, strike that out then".
There's one big limitation I find with Perl 5.8. It's slow. Don't get me wrong it's fast enough in many cases.
:).
:)
BUT if it was 20-30 times faster people would be able to use it for a lot more stuff where they'd otherwise have to resort to stuff that involves a lot more work
Parrot hasn't been very impressive, and ponie is dead anyway.
Yeah I know python is a bit faster and cleaner but so far it doesn't seem like a huge improvement.
I've looked at Lisp and I've come to the conclusion that:
Lisp is powerful for all the code you write, unfortunately you still have to write a lot of that code yourself.
In contrast Perl is powerful because of all the code you don't have to write.