Want to go green? Use CFLs. Replace your shower heads. Bike to work. Email instead of printing. Open windows rather than hit the thermostat. Use GotoMeeting rather than fly. Plant some trees on the South side of your home and office buildings. Buy your food from a local Farmer's Market rather than the mega-mart to avoid 'fresh' food from Argentina or some other place 4,000 miles away in refrigerated containers.
Not all those things are as big a save as all that. While some make a lot of sense (going away from incandescent lights for example) the Farmer's Market idea might not be as effective as you hope. The issue there is that you've got to compare not just the transport costs to the environment, but also the production costs; growing veg in a heated greenhouse in the middle of winter is not carbon-efficient! Instead, you have to accept far more seasonality in the goods that you buy.
And meetings continue to be far more effective when carried out in person. The tools available on the internet just aren't good enough yet for anything beyond point-to-point meeting-alikes and broadcasts. (Alas, this means I've seen the inside of far too many airports.) The key issues are that people never get their configurations right - kind-of vital for many-to-many comms to work! - and you can't really share a drink or meal with someone over the internet. It's a human thing.
The real "green" thing to do is get rid of the grass and use native plants and grasses for the landscape. That would also cut down on water use.
But wouldn't necessarily get rid of the fire hazard, which is Google's primary requirement here, since the native flora of that part of California is highly flammable.
If you really hate it that much, you can get away with writing a pretty thin wrapper of Obj-C to interface to the OSX specific APIs (most of your calls will probably be standard libc calls in C anyway), and have almost all of your code in C/C++.
While you are wrong about most calls to the OSX APIs being standard C calls (just not true for Cocoa apps) you should be aware that it is not that difficult to call Obj-C code using its conventions from plain old C. It does take a bunch of code but you really don't have to use Obj-C, despite it being easier (as in: less code to write and get right...)
About the only thing that you could theoretically object to about Obj-C (in an "objective" fashion) is the fact that the Obj-C calling convention is slower than those of C and C++. (Sorry about the puns.) While I don't have the figures, I would note that this is not necessarily a problem in practice since the method dispatch low-level function is "hot" and cached.
I once tried stealing one of the disks and booting up from a lounge back in my dorm, with text books and a calculator at hand, but they were smart enough to block connections to the test server from outside the testing rooms.
The other thing they could do quite easily is to lock out clients when it is not time to take a particular exam. Back when I was writing software for exam taking (7 years ago) I used tricks like this.
The system can definitely work, when properly implemented.
Absolutely. The main problem has got to be that most of the people writing the software are just not very good programmers. You can't configure and deploy a sow's ear as a silk purse.
I think you mean "plain," unless you think Spain is covered in aircraft or woodworking tools. Hoisted by your own petard, eh?
Perhaps the GP was referring to a flat unbounded surface defined by a point and a normal vector? (Not that I've actually seen one of those in Spain, you understand...)
That could have been the solution to a lot of the CIA's problems. I wonder if they would have gotten more info out of suspects had they rendered them off to the Netherlands instead of Syria.
It would have given them a few other ways to carry out interrogations too.
If you don't know them, you're not a programmer. If you don't ever implement them, you're likely shipping more library code than application code.
You spend clients' money writing sorting algorithms rather than just using the well-implemented ones that already exist for every production language I've ever heard of? (The algorithms you need to be aware of here for the in-memory cases are quicksort, mergesort, and insertion sort. If it doesn't fit in memory, it's probably better to let a database engine take care of the details.)
* Creating your own GUIs
Umm.. well actually..
I did RTFA and the point is about doing the low-level pixel bashing. It's much easier to use a toolkit library to handle those bits, and it's doubly easier to use one developed by other people. (Not everyone has to reinvent GTK...)
* GO TO and spaghetti code
goto is considered harmful, but it doesn't mean it isn't useful. Spaghetti code, yeah, that's the norm.
Did you know that you can use OO techniques to spread the spaghetti across thousands of classes? Thousands of methods, all called doit(). Grrr!
* Manual multithreading
All the time. select() is your friend, learn it.
You're better off encapsulating all the tricky bits in one spot/file and then just using them everywhere else. Less efficient, sure, but so much easier to make work.
* Self-modifying code
Yup, I actually write asm code.. plus he mentions "modifying the code while it's running".. if you can't do that, you shouldn't be wielding a debugger, edit and continue, my ass.
SMC is terrible for performance. Avoid if possible, use a tool to do it (correctly!) for you otherwise. That's how things like debuggers work.
* Memory management
Yeah, garbage collection is cheap and ubiquitous, and I'm one of the few people that has used C++ garbage collection libraries in serious projects.. that said, I've written my own implementations of malloc/free/realloc and gotten better memory performance. It's what real programmers do to make 64 gig of RAM enough for anyone.
If you can use GC, do so. With much experience, it saves a lot of hair-tearing...
* Math and date conversions
Every day.
This is another one where using a library is a good idea. Date processing is stupidly difficult to get right.
* Making code run faster
Every fucking day. If you don't do this then you're a dweeb who might as well be coding in php.
Faster by smarter algorithms and cache management? Great. Faster by dicking around with instruction ordering? Leave that to the freaking compiler
* Being patient
"Hey, we had a crash 42 hours into the run, can you take a look?" "Sure, it'll take me about 120 hours to get to it with a debug build."
I feel your pain. "Did you save a crash dump for me?" is a useful question there...
That's a terrible way of doing it! It guarantees that the compiler and processor can't do anything smart with reordering variable accesses since the values are now officially dependent on each other, despite not really being.
As a python user I've always been confused by this one
x,y = y,x
Is the easiest way to do it surely?
Yes, but you should be aware that the system is creating (at least) one temporary behind the scenes to hold those values while they're being swapped over. Which isn't to say don't write that! The method you use has the strong advantage of being really easy to get right, as opposed to that idiotic xor "idiom"...
If you know the set of values your string can take, you can compute a perfect hash (if you want). There's even a tool to do it.
You can, just as you can pre-size the array of hash buckets, but it's probably a mistake to do so. The costs of using a generic algorithm are really quite small unless your hash function is stupidly expensive, and then when some wiseguy decides to expand the problem-space you don't need to do anything special.
Why? The one year old child has had significantly fewer resources invested in it, than the 1000 year old monastery which had to be built by hand and then maintained for 1000 years.
It would take the parents maybe....two years, and less than $100,000 to recreate another one year old child. The point I'm making is that, human life is important, but I don't believe it's something to be held on such a high pedestal.
The insurance industry has this all worked out. People value human lives at a few million bucks (no, I don't remember how much exactly) as in that's how much people will actually spend to save a life. Callous for sure, but true all the same.
From my experience this is a bit of an exaggeration. It's true that EU-funded projects have more strings attached than those from many other funding sources, but running the burocracy/reports/financials for an EU project that is funding 3 full time people at our university still only takes a rather small percentage of my time.
That really depends on the details of the project. STREPs (small projects) tend to be easier that way than IPs (big "integrated" projects), and a great deal is down to how much paperwork was designed in by the project management. IMO (and with a few years' experience now) you're best off trying to minimize the number of Work Packages that you're in; that helps a lot with keeping the paperwork monkey off your back.
BTW, it's very worthwhile doing EU projects since they give you a chance to work with other talented people doing cutting edge research and combining what you want to do into a whole that is greater than the sum of the parts. But like any opportunity, it's up to you to not waste it...
Until other countries deal with their fraud issues, there is no way that online merchants of any kind are going to accept credit cards from outside of the US. The risk is waaaay too high.
What about plans to deal with credit card fraud risk from inside the US?
But expecting Joe Six-pack to deal with maven builds, hierarchical make files, and package dependency graphs
I write software, but maven builds, hierarchic make and dependency graphs still make me uneasy. (Yes, I use them. I reckon that makes me qualified to say that they're scarily complex...)
You would be significantly weakening a competitor, and creating a level playing field. Sure, the profits wouldn't be as obscene as under an artificial monopoly, but you could still profit from printing the books.
No you wouldn't. You'd be in prison or executed, and the publishing corporation would be wound up without compensation to shareholders. Society at large doesn't tolerate outright murder for financial gain, and to think that you can get away with it... foolish. (Not to mention the fact that you'd never be in with a chance to have a big hit yourself either, not and hold onto it.)
It would take a single programmer about three weeks, depending on the state of the code.
My bet is that it's not just changing a few drivers. There's probably a custom communications link inside (to reduce power use and weight, critical things for a phone) and it's quite possible that the hardware itself is different. (Did Apple put reconfigurable hardware inside the comms module? If not, or not enough, switching to CDMA might be a lot of work...)
And anyway, it's only for one market. Easier for Apple to just blow off Verizon.
What if someone has forged the BofA email headers? Or the Yahoo headers. I've seen this all too often.
The spammers can't forge a legit Received: header chain; it involves too many pieces that they don't control. Do you think that BofA would route email through some home PC in South Korea or a university? (If so, are you sure you want to have a business relationship with them at all...?)
If you are doing Received: examination, remember that you must examine the whole chain and not just the last/first entry. Some parts of it may be bogus. The best point to look is the place where the message entered onto the sequence of known-good systems leading to your mailbox (might be one step, might be loads; depends on your setup).
If your mail client won't show Received: headers when asked nicely (they're big and so not shown by default) get a better mail client.
It is for people running bittorrent, where people typically restrict download rates to peers to a small fixed multiple of that peer's upload speed.
(Much as I hate BT in practice, it's got some interesting network and protocol characteristics. Just wish it was friendlier on non-users, given the reality that downlink bandwidth is larger than uplink bandwidth for most people...)
Sure things might get hairy for a while but seriously global warming isn't that dangerous to our survival as a race.
Now that is an interesting assertion. Do you have some evidence to back it up? (Also, I'd quite like civilization to survive too. Call me strange if you wish...)
Slashdot Mirror
Want to go green? Use CFLs. Replace your shower heads. Bike to work. Email instead of printing. Open windows rather than hit the thermostat. Use GotoMeeting rather than fly. Plant some trees on the South side of your home and office buildings. Buy your food from a local Farmer's Market rather than the mega-mart to avoid 'fresh' food from Argentina or some other place 4,000 miles away in refrigerated containers.
Not all those things are as big a save as all that. While some make a lot of sense (going away from incandescent lights for example) the Farmer's Market idea might not be as effective as you hope. The issue there is that you've got to compare not just the transport costs to the environment, but also the production costs; growing veg in a heated greenhouse in the middle of winter is not carbon-efficient! Instead, you have to accept far more seasonality in the goods that you buy.
And meetings continue to be far more effective when carried out in person. The tools available on the internet just aren't good enough yet for anything beyond point-to-point meeting-alikes and broadcasts. (Alas, this means I've seen the inside of far too many airports.) The key issues are that people never get their configurations right - kind-of vital for many-to-many comms to work! - and you can't really share a drink or meal with someone over the internet. It's a human thing.
The real "green" thing to do is get rid of the grass and use native plants and grasses for the landscape. That would also cut down on water use.
But wouldn't necessarily get rid of the fire hazard, which is Google's primary requirement here, since the native flora of that part of California is highly flammable.
If you really hate it that much, you can get away with writing a pretty thin wrapper of Obj-C to interface to the OSX specific APIs (most of your calls will probably be standard libc calls in C anyway), and have almost all of your code in C/C++.
While you are wrong about most calls to the OSX APIs being standard C calls (just not true for Cocoa apps) you should be aware that it is not that difficult to call Obj-C code using its conventions from plain old C. It does take a bunch of code but you really don't have to use Obj-C, despite it being easier (as in: less code to write and get right...)
About the only thing that you could theoretically object to about Obj-C (in an "objective" fashion) is the fact that the Obj-C calling convention is slower than those of C and C++. (Sorry about the puns.) While I don't have the figures, I would note that this is not necessarily a problem in practice since the method dispatch low-level function is "hot" and cached.
I once tried stealing one of the disks and booting up from a lounge back in my dorm, with text books and a calculator at hand, but they were smart enough to block connections to the test server from outside the testing rooms.
The other thing they could do quite easily is to lock out clients when it is not time to take a particular exam. Back when I was writing software for exam taking (7 years ago) I used tricks like this.
The system can definitely work, when properly implemented.
Absolutely. The main problem has got to be that most of the people writing the software are just not very good programmers. You can't configure and deploy a sow's ear as a silk purse.
I think you mean "plain ," unless you think Spain is covered in aircraft or woodworking tools. Hoisted by your own petard, eh?
Perhaps the GP was referring to a flat unbounded surface defined by a point and a normal vector? (Not that I've actually seen one of those in Spain, you understand...)
(Someone please feel free to electorate on what I have said :) )
Really? Oh, OK. If you insist. Try the following (and yes, I know this isn't a secret ballot; I don't care)...
I vote that you used the word "electorate" to mean "elaborate", and that you'd have been better sticking to plain old "expand".
That could have been the solution to a lot of the CIA's problems. I wonder if they would have gotten more info out of suspects had they rendered them off to the Netherlands instead of Syria.
It would have given them a few other ways to carry out interrogations too.
"Dude! Where's your bomb?"
no MS basher responses please
Awwwww! Please? Just one? A little one?
* Sorting algorithms
If you don't know them, you're not a programmer. If you don't ever implement them, you're likely shipping more library code than application code.
You spend clients' money writing sorting algorithms rather than just using the well-implemented ones that already exist for every production language I've ever heard of? (The algorithms you need to be aware of here for the in-memory cases are quicksort, mergesort, and insertion sort. If it doesn't fit in memory, it's probably better to let a database engine take care of the details.)
* Creating your own GUIs
Umm.. well actually..
I did RTFA and the point is about doing the low-level pixel bashing. It's much easier to use a toolkit library to handle those bits, and it's doubly easier to use one developed by other people. (Not everyone has to reinvent GTK...)
* GO TO and spaghetti code
goto is considered harmful, but it doesn't mean it isn't useful. Spaghetti code, yeah, that's the norm.
Did you know that you can use OO techniques to spread the spaghetti across thousands of classes? Thousands of methods, all called doit(). Grrr!
* Manual multithreading
All the time. select() is your friend, learn it.
You're better off encapsulating all the tricky bits in one spot/file and then just using them everywhere else. Less efficient, sure, but so much easier to make work.
* Self-modifying code
Yup, I actually write asm code.. plus he mentions "modifying the code while it's running".. if you can't do that, you shouldn't be wielding a debugger, edit and continue, my ass.
SMC is terrible for performance. Avoid if possible, use a tool to do it (correctly!) for you otherwise. That's how things like debuggers work.
* Memory management
Yeah, garbage collection is cheap and ubiquitous, and I'm one of the few people that has used C++ garbage collection libraries in serious projects.. that said, I've written my own implementations of malloc/free/realloc and gotten better memory performance. It's what real programmers do to make 64 gig of RAM enough for anyone.
If you can use GC, do so. With much experience, it saves a lot of hair-tearing...
* Math and date conversions
Every day.
This is another one where using a library is a good idea. Date processing is stupidly difficult to get right.
* Making code run faster
Every fucking day. If you don't do this then you're a dweeb who might as well be coding in php.
Faster by smarter algorithms and cache management? Great. Faster by dicking around with instruction ordering? Leave that to the freaking compiler
* Being patient
"Hey, we had a crash 42 hours into the run, can you take a look?"
"Sure, it'll take me about 120 hours to get to it with a debug build."
I feel your pain. "Did you save a crash dump for me?" is a useful question there...
Now you know!
That's a terrible way of doing it! It guarantees that the compiler and processor can't do anything smart with reordering variable accesses since the values are now officially dependent on each other, despite not really being.
As a python user I've always been confused by this one
Is the easiest way to do it surely?
Yes, but you should be aware that the system is creating (at least) one temporary behind the scenes to hold those values while they're being swapped over. Which isn't to say don't write that! The method you use has the strong advantage of being really easy to get right, as opposed to that idiotic xor "idiom"...
If you know the set of values your string can take, you can compute a perfect hash (if you want). There's even a tool to do it.
You can, just as you can pre-size the array of hash buckets, but it's probably a mistake to do so. The costs of using a generic algorithm are really quite small unless your hash function is stupidly expensive, and then when some wiseguy decides to expand the problem-space you don't need to do anything special.
Why? The one year old child has had significantly fewer resources invested in it, than the 1000 year old monastery which had to be built by hand and then maintained for 1000 years.
It would take the parents maybe....two years, and less than $100,000 to recreate another one year old child. The point I'm making is that, human life is important, but I don't believe it's something to be held on such a high pedestal.
The insurance industry has this all worked out. People value human lives at a few million bucks (no, I don't remember how much exactly) as in that's how much people will actually spend to save a life. Callous for sure, but true all the same.
From my experience this is a bit of an exaggeration. It's true that EU-funded projects have more strings attached than those from many other funding sources, but running the burocracy/reports/financials for an EU project that is funding 3 full time people at our university still only takes a rather small percentage of my time.
That really depends on the details of the project. STREPs (small projects) tend to be easier that way than IPs (big "integrated" projects), and a great deal is down to how much paperwork was designed in by the project management. IMO (and with a few years' experience now) you're best off trying to minimize the number of Work Packages that you're in; that helps a lot with keeping the paperwork monkey off your back.
BTW, it's very worthwhile doing EU projects since they give you a chance to work with other talented people doing cutting edge research and combining what you want to do into a whole that is greater than the sum of the parts. But like any opportunity, it's up to you to not waste it...
Until other countries deal with their fraud issues, there is no way that online merchants of any kind are going to accept credit cards from outside of the US. The risk is waaaay too high.
What about plans to deal with credit card fraud risk from inside the US?
But expecting Joe Six-pack to deal with maven builds, hierarchical make files, and package dependency graphs
I write software, but maven builds, hierarchic make and dependency graphs still make me uneasy. (Yes, I use them. I reckon that makes me qualified to say that they're scarily complex...)
How do you kill that which has no life?
You call in Judge Dredd. Duh!
You would be significantly weakening a competitor, and creating a level playing field. Sure, the profits wouldn't be as obscene as under an artificial monopoly, but you could still profit from printing the books.
No you wouldn't. You'd be in prison or executed, and the publishing corporation would be wound up without compensation to shareholders. Society at large doesn't tolerate outright murder for financial gain, and to think that you can get away with it... foolish. (Not to mention the fact that you'd never be in with a chance to have a big hit yourself either, not and hold onto it.)
It would take a single programmer about three weeks, depending on the state of the code.
My bet is that it's not just changing a few drivers. There's probably a custom communications link inside (to reduce power use and weight, critical things for a phone) and it's quite possible that the hardware itself is different. (Did Apple put reconfigurable hardware inside the comms module? If not, or not enough, switching to CDMA might be a lot of work...)
And anyway, it's only for one market. Easier for Apple to just blow off Verizon.
Or PERHAPS he should try WRITING scripts for SUPERHERO COMICS.
Maybe his SECRET ALTER-EGO is none-other than BILL GRIFFITH.
What if someone has forged the BofA email headers? Or the Yahoo headers. I've seen this all too often.
The spammers can't forge a legit Received: header chain; it involves too many pieces that they don't control. Do you think that BofA would route email through some home PC in South Korea or a university? (If so, are you sure you want to have a business relationship with them at all...?)
If you are doing Received: examination, remember that you must examine the whole chain and not just the last/first entry. Some parts of it may be bogus. The best point to look is the place where the message entered onto the sequence of known-good systems leading to your mailbox (might be one step, might be loads; depends on your setup).
If your mail client won't show Received: headers when asked nicely (they're big and so not shown by default) get a better mail client.
If i continue to live, am a threat to the Hearse makers consortium.
No, you're just a futures contract to them.
we are going to have to put some human beings somewhere else besides this one ball of rock.
That's not true. We could let the human race go extinct instead. Much cheaper. The true economist's choice.
The uplink speed is not really that interesting.
It is for people running bittorrent, where people typically restrict download rates to peers to a small fixed multiple of that peer's upload speed.
(Much as I hate BT in practice, it's got some interesting network and protocol characteristics. Just wish it was friendlier on non-users, given the reality that downlink bandwidth is larger than uplink bandwidth for most people...)
Sure things might get hairy for a while but seriously global warming isn't that dangerous to our survival as a race.
Now that is an interesting assertion. Do you have some evidence to back it up? (Also, I'd quite like civilization to survive too. Call me strange if you wish...)