Biggest problem I have with government is it spends whatever it likes, regardless how much I pay in taxes.
This. Why should we feel morally compelled to offer up MORE of our hard earned money to a group of people who are completely unable to responsibly handle what we already give them? Even if we turned over our entire yearly incomes and lived off the land, they'd still find a way to utterly piss it all away and we'd be in the same boat. Blaming *us* for the state's financial woes is blaming the victim. The state needs to get its own shit straight before they go pointing the finger at anybody else.
It's hard to have sympathy for the state's plight. When the state announced they were going to close 70 state parks private individuals donated money in an attempt to keep some of those parks open.
Then it turned out that up to $54 million was squirrelled away, for still murky reasons, that should of gone to funding the parks.
If CA finances are this much of a mess how can Californians in good conscious be asked to pay yet more in tax hikes?
I don't see where it's refuted by the same qualitative source as a published scientific paper. And cellulosic ethanol? That's been attempted for over 100 years and nobody has been able to scale it up to get a positive energy return on it for the reason I mentioned. It simply takes too much energy to remove the water.
The idea we can consume the same amount of energy by growing biomass is a pipe dream. Many of the processes that produce liquid fuels via biological processes end requiring more input energy that can be extracted, usually because water has to be removed from the final product which requires heat. That is why so many companies have been able to succeed building pilot projects but can never scale up to anything sustainable.
Just to be clear, uranium hexafluoride is used in the process of enriching uranium via gaseous diffusion, and as the article states there have been some accidents involving trucks carrying canisters of it. But by the time it's in a warhead it's back in metal form.
"For instance, a 2004 rule that gives oil and other companies a special deduction for their U.S. operations could save the oil industry $18.2 billion over 10 years. "
What are you talking about? That "2004 rule" is Section 199. It's not limited to just oil companies.
I agree.. The new iPhone is really, really well done. Siri is so simple that my grandma can use the iPhone. This is clearly a time where profits were earned through innovation and delivery, not just accounting tricks. Exxon being the second closet company gets their product for nearly free, so this is definitely an accomplishment. The question is, without Steve is this sustainable.
You don't know much about the petroleum business if you think oil companies don't need to reinvest heavily to keep production up. That's the why often a nationalized oil company(say Venezuela's PDVSA) will show a sharp drop in production numbers as time goes. The profits are used for social welfare programs instead of reinvestment.
But - How come we don't hear the politicians demanding a "windfall profits tax" like they did with Exxon two years ago? I guess it's only bad to make a profit if you're an evil oil company, but if your a tech company it's a good thing to rake-in equivalent amounts of money.
Um because Exxon was collecting subsidies from the US government at the same time they were making extreme amounts of profit. I am unaware that Congress enacted laws to give Apple subsidies. Also Exxon moved their headquarters to Switzerland to reduce taxes than Apple which is still an American company. Now if you go down to Houston, the buildings and workers are still there. They just moved to Switzerland on paper.
Not true. The biggest "subsidy" given to Exxon is the Section 199 deduction. Apple(and other tech companies) take the same deduction. Apple even gets a bigger deduction from it - 9% vs. 6%.
Just because Adobe and Microsoft are abandoning the Flash and Silverlight run time environments doesn't necessarily mean they're also abandoning their respective Dynamic Streaming and Smooth Streaming protocols. Being HTTP based I'd think it'd be a natural fit for an HTML5 video player in a browser to use these protocols.
In my experience the way the socket API can slow down a processor is having to monitor many thousands of socket descriptors using select() or poll(), like in a web server. For Linux epoll() was created for this scenario.
Correct me if I'm wrong, but generally speaking, I was always under the impression that, as an interpreted language, javascript will never be able to run 100% as fast as natively compiled C code.
A real world Javascript program will rarely, if ever, be as fast as C. The idea with this is: Normally, loops, no matter how tight, are executed in the interpreter environment with all the overhead that it entails. The idea is to profile loops that are 'hot' enough to be compiled to machine code so that the following iterations don't have the overhead of the interpreter. The more iterations for a loop the potentially faster speedup. Since compiling in itself takes time obviously part of the profiling will be to determine if a loop is worth compiling or not.
I work at a very large telecom on their enterprise level network routers. Our code base is almost entirely C. I, and a few others, have been moving parts over to C++ mostly for what C++ and Boost can offer. There is a standard Red-Black binary tree library in VxWorks(probably all Unixes: rbtLib.h). Needing two or more sets of ordering on the same data is a hack. You create two binary trees and cast different structs before dereferencing it. I've done it. I then tried the multi index set in Boost and you know what? Each entry takes up EXACTLY the same amount of data as when I hand coded it in C. What's great about C++ is you can use it as a better C. Define all your types and use the implicit constructor calls to range check all with assert() when you develop.
I've also interviewed at Redback and they are entirely a C shop. Some of it is old entrenchment, but some of it is needing to know exactly what happens in their code. I have mixed feelings about that.
On the other hand, C is the lowest you can get across processor architectures. You have complete confidence knowing exactly how much memory a structure will take up, with knowledge of boundary alignemnt of course. Saving it to disk and loading it back is straight forward. Have one virtual function in a C++ class or structure and doing that will cause trouble as the compiler will put a pointer to a vtable at the beginning. From a simple debug shell I've had to debug a chip vendor's function by calling malloc and passing the address back to the API function to DMA a hardware table into memory. Have you seen what function overloading causes the compiler to do with the entries in the symbol table? My whole point is that abstraction leaks will always occur, and when someone has to go to the lower level to debug, these higher level constructs cause more confusion.
C isn't going anywhere, at least not in the some what niche area of network software programming.
C++ has nothing to do with it. Memory fragmentation is caused when memory is constantly allocated and freed back to the heap, causing fragmentation over time. Linux has a slab allocator that is used by the kernel and available to user applications to avoid this sort of problem. However, how an application allocates and frees memory also has an effect on fragmentation.
A slab allocator was first introduced into Solaris. Not sure what Windows has.
C++ has nothing to do with it. Memory fragmentation is caused when memory is freed and returned to the heap, causing fragmentation over time. Linux has a slab allocator that is used by the kernel and available to user applications, to avoid this sort of problem.
A slab allocator was first introduced into Solaris. Not sure what Windows has.
I haven't messed with Java for the last few years but I do remember working with some developers and testers on a network management application that was written in Java. It was a memory hog and there were some big issues with leaks, which made me wonder if there were some flaws in the garbage collection. I'm sure Sun's JRE has gotten better by now.
If you want something a little smarter in C++, look up smart pointers and the Boost library. Basically takes advantage that an object's destructor is called when the object goes out of context. Throw in a couple operator overloads and you have the equivalent of a pointer that frees memory back to the heap itself. Similar concept to semaphores that release themselves.
I agree, the "Unix way" has been to try to always run separate processes. Threads are seen to some as a 'hack' when IPC methods such a sockets cost too much. Read Raymond's "The Art of UNIX Programming" as an example. But then when you have to serialize access to memory(eg. semaphores), that also costs time.
I work for a big telecom in their enterprise network router division. We're in the process of starting to move from VxWorks to Linux. VxWorks has no concept of memory protection. A VxWorks task would be the equivalent of a thread in Linux. Yes, each task has it's own stack, but it's more of a scheduling mechanism but not for memory protection. For Linux we're pretty much going to map every task to it's own process, but defining a common memory area for data that multiple processes need(eg. switch port status). We already have to move our socket code from a custom implementation(won't work under Linux) to a TCP style. The later is a lot more robust and the current implementation we have actually lets us register our own callbacks instead of having to deal with select loops, so it's pretty quick to get up to snuff. But the one big area of work up ahead is the code is replete with direct function calls to other tasks. Which obviously are going to break when these guys get mapped to processes under Linux. But I agree with you about stability. Some of the more insidious bugs we've had has been when one task over writes another tasks data or TCB. Took a lot of man hours to figure out, and I would equate them to a nasty memory leak.
Getting off the fossil fuel teat isn't going to be easy. The basic fact is that fossil fuels are the accumulation of solar energy over millions and millions of years. Renewable fuels are the accumulation of energy over a few months. It's not so simple to simply grow our way out of this problem. The fact is that even with biofuels, the human race is going to be in for a rude awakening with regards to its energy consumption.
4. MAC address ARE NOT UNIQUE! They are nearly unique, but if you operate under the idea that mac addresses are unique then your life will be hell when you have to track down a duplicate MAC on a large enterprise network because you believe it cannot happen. It does, although infrequently, and it makes networking very very 'interesting' when it happens.
I've always wondered how prevalent this is. The most significant 24bits are the vendor ID and the least significant are "supposed" to be unique within that vendor. Larger vendors have more then one vendor ID. So does a large NIC manufacturer reuse those lower 24 bits frequently? You can do a lookup for vendor IDs here: http://coffer.com/mac_find/
Had ~3000 Dell PCs on an enterprise network. Our routers were having a problem because the Broadcom chips we were using hash the layer 2 table index based on the SA and VLAN. Buckets were 8 entries deep. Well, take ~3000 MACs with the same upper 24 bits and we had conflicts. Even though the MSBs were the same, don't remember seeing the LSBs repeating. Of course 3000 is easy to randomly fit into ~16 million.
Very interesting.
Just a couple weeks ago NPR had an interview with three doctors about how the body's inflammation response is turning out to play a much larger role in diseases then previously thought.
link
Let them invent something that will lást a decade, instead of break down after two or three years. Wait, didn't they already build fridges, washing-machines and T.V.-s that would last that long in the seventies? Gee, I wonder what happened to technology. O yes, I know, they improved it...
There really is something to be said to the old adage, "They don't make 'em like they used to."
I have a 33 year old Kenmore refrigerator/freezer that my father gave me. It's older then myself. Still going strong. Going to get something newer that looks nicer and is more efficient but I don't think it'll last half as long.
And what about furniture? I can go to Goodwill and find old wood furniture that's better made then much of what you can buy new today, except for the more expensive stuff. Things like dressers with drawers that are held together with dovetail joints. Sure, it's finish is pitted and beaten, but you can strip the varnish down and sand the top. Then either oil it or revarnish it and it'll look beautiful. For someone starting off furnishing their first pad I recommend this over going to Ikea if they don't mind using some elbow grease.
The quote reminds me of my younger years when I had to... um... quickly dry things I grew before they rotted.
Take a tupperware container. Wedge two layers of chicken wire, with a few inches between the bottom, middle, and top. On the bottom layer of wire put a cotton cloth with Damp Rid(Potassium Chloride). Put the items you want to dehydrate on the top layer. Seal up. The salt will leech the water out and when it saturates, dump it at the bottom of the container.
So given a big enough contraption to hold enough salt with a large enough surface area, a way to move enough air over it(fan), and a way to get the water out and stored(pump), could you collect 600 gallons of a water a day in a desert?
Slashdot Mirror
Biggest problem I have with government is it spends whatever it likes, regardless how much I pay in taxes.
This. Why should we feel morally compelled to offer up MORE of our hard earned money to a group of people who are completely unable to responsibly handle what we already give them? Even if we turned over our entire yearly incomes and lived off the land, they'd still find a way to utterly piss it all away and we'd be in the same boat. Blaming *us* for the state's financial woes is blaming the victim. The state needs to get its own shit straight before they go pointing the finger at anybody else.
It's hard to have sympathy for the state's plight. When the state announced they were going to close 70 state parks private individuals donated money in an attempt to keep some of those parks open.
Then it turned out that up to $54 million was squirrelled away, for still murky reasons, that should of gone to funding the parks.
If CA finances are this much of a mess how can Californians in good conscious be asked to pay yet more in tax hikes?
http://abclocal.go.com/kgo/story?section=news/politics&id=8750455
And for renewables that are driven by sun or wind, that cost is surface area.
I don't see where it's refuted by the same qualitative source as a published scientific paper. And cellulosic ethanol? That's been attempted for over 100 years and nobody has been able to scale it up to get a positive energy return on it for the reason I mentioned. It simply takes too much energy to remove the water.
A paper by a professor named Jeff Dukes back in 1997 calculated that in that year we burned 400 years worth of biomass using fossil fuels.
http://plus.maths.org/content/burning-buried-sunshine
The idea we can consume the same amount of energy by growing biomass is a pipe dream. Many of the processes that produce liquid fuels via biological processes end requiring more input energy that can be extracted, usually because water has to be removed from the final product which requires heat. That is why so many companies have been able to succeed building pilot projects but can never scale up to anything sustainable.
Just to be clear, uranium hexafluoride is used in the process of enriching uranium via gaseous diffusion, and as the article states there have been some accidents involving trucks carrying canisters of it. But by the time it's in a warhead it's back in metal form.
"For instance, a 2004 rule that gives oil and other companies a special deduction for their U.S. operations could save the oil industry $18.2 billion over 10 years. "
What are you talking about? That "2004 rule" is Section 199. It's not limited to just oil companies.
I agree.. The new iPhone is really, really well done. Siri is so simple that my grandma can use the iPhone. This is clearly a time where profits were earned through innovation and delivery, not just accounting tricks. Exxon being the second closet company gets their product for nearly free, so this is definitely an accomplishment. The question is, without Steve is this sustainable.
You don't know much about the petroleum business if you think oil companies don't need to reinvest heavily to keep production up. That's the why often a nationalized oil company(say Venezuela's PDVSA) will show a sharp drop in production numbers as time goes. The profits are used for social welfare programs instead of reinvestment.
In 2010 Exxon reinvested $28 billion
But - How come we don't hear the politicians demanding a "windfall profits tax" like they did with Exxon two years ago? I guess it's only bad to make a profit if you're an evil oil company, but if your a tech company it's a good thing to rake-in equivalent amounts of money.
Um because Exxon was collecting subsidies from the US government at the same time they were making extreme amounts of profit. I am unaware that Congress enacted laws to give Apple subsidies. Also Exxon moved their headquarters to Switzerland to reduce taxes than Apple which is still an American company. Now if you go down to Houston, the buildings and workers are still there. They just moved to Switzerland on paper.
Not true. The biggest "subsidy" given to Exxon is the Section 199 deduction. Apple(and other tech companies) take the same deduction. Apple even gets a bigger deduction from it - 9% vs. 6%.
Just because Adobe and Microsoft are abandoning the Flash and Silverlight run time environments doesn't necessarily mean they're also abandoning their respective Dynamic Streaming and Smooth Streaming protocols. Being HTTP based I'd think it'd be a natural fit for an HTML5 video player in a browser to use these protocols.
In my experience the way the socket API can slow down a processor is having to monitor many thousands of socket descriptors using select() or poll(), like in a web server. For Linux epoll() was created for this scenario.
I think Python would be a great choice. You could start off with entering simple expressions in interactive mode then go from there.
Correct me if I'm wrong, but generally speaking, I was always under the impression that, as an interpreted language, javascript will never be able to run 100% as fast as natively compiled C code.
A real world Javascript program will rarely, if ever, be as fast as C. The idea with this is: Normally, loops, no matter how tight, are executed in the interpreter environment with all the overhead that it entails. The idea is to profile loops that are 'hot' enough to be compiled to machine code so that the following iterations don't have the overhead of the interpreter. The more iterations for a loop the potentially faster speedup. Since compiling in itself takes time obviously part of the profiling will be to determine if a loop is worth compiling or not.
I work at a very large telecom on their enterprise level network routers. Our code base is almost entirely C. I, and a few others, have been moving parts over to C++ mostly for what C++ and Boost can offer. There is a standard Red-Black binary tree library in VxWorks(probably all Unixes: rbtLib.h). Needing two or more sets of ordering on the same data is a hack. You create two binary trees and cast different structs before dereferencing it. I've done it. I then tried the multi index set in Boost and you know what? Each entry takes up EXACTLY the same amount of data as when I hand coded it in C. What's great about C++ is you can use it as a better C. Define all your types and use the implicit constructor calls to range check all with assert() when you develop.
I've also interviewed at Redback and they are entirely a C shop. Some of it is old entrenchment, but some of it is needing to know exactly what happens in their code. I have mixed feelings about that.
On the other hand, C is the lowest you can get across processor architectures. You have complete confidence knowing exactly how much memory a structure will take up, with knowledge of boundary alignemnt of course. Saving it to disk and loading it back is straight forward. Have one virtual function in a C++ class or structure and doing that will cause trouble as the compiler will put a pointer to a vtable at the beginning. From a simple debug shell I've had to debug a chip vendor's function by calling malloc and passing the address back to the API function to DMA a hardware table into memory. Have you seen what function overloading causes the compiler to do with the entries in the symbol table? My whole point is that abstraction leaks will always occur, and when someone has to go to the lower level to debug, these higher level constructs cause more confusion.
C isn't going anywhere, at least not in the some what niche area of network software programming.
When did Billy Corgan from The Smashing Pumpkins start working in IT?
C++ has nothing to do with it. Memory fragmentation is caused when memory is constantly allocated and freed back to the heap, causing fragmentation over time. Linux has a slab allocator that is used by the kernel and available to user applications to avoid this sort of problem. However, how an application allocates and frees memory also has an effect on fragmentation.
A slab allocator was first introduced into Solaris. Not sure what Windows has.
C++ has nothing to do with it. Memory fragmentation is caused when memory is freed and returned to the heap, causing fragmentation over time. Linux has a slab allocator that is used by the kernel and available to user applications, to avoid this sort of problem.
A slab allocator was first introduced into Solaris. Not sure what Windows has.
I haven't messed with Java for the last few years but I do remember working with some developers and testers on a network management application that was written in Java. It was a memory hog
and there were some big issues with leaks, which made me wonder if there were some flaws in the garbage collection. I'm sure Sun's JRE has gotten better by now.
If you want something a little smarter in C++, look up smart pointers and the Boost library. Basically takes advantage that an object's destructor
is called when the object goes out of context. Throw in a couple operator overloads and you have the equivalent of a pointer
that frees memory back to the heap itself. Similar concept to semaphores that release themselves.
I agree, the "Unix way" has been to try to always run separate processes. Threads are seen to some as a 'hack' when IPC methods such a sockets cost too much. Read Raymond's "The Art of UNIX Programming" as an example. But then when you have to serialize access to memory(eg. semaphores), that also costs time.
I work for a big telecom in their enterprise network router division. We're in the process of starting to move from VxWorks to Linux. VxWorks has no concept of memory protection. A VxWorks task would be the equivalent of a thread in Linux. Yes, each task has it's own stack, but it's more of a scheduling mechanism but not for memory protection. For Linux we're pretty much going to map every task to it's own process, but defining a common memory area for data that multiple processes need(eg. switch port status). We already have to move our socket code from a custom implementation(won't work under Linux) to a TCP style. The later is a lot more robust and the current implementation we have actually lets us register our own callbacks instead of having to deal with select loops, so it's pretty quick to get up to snuff. But the one big area of work up ahead is the code is replete with direct function calls to other tasks. Which obviously are going to break when these guys get mapped to processes under Linux. But I agree with you about stability. Some of the more insidious bugs we've had has been when one task over writes another tasks data or TCB. Took a lot of man hours to figure out, and I would equate them to a nasty memory leak.
Getting off the fossil fuel teat isn't going to be easy. The basic fact is that fossil fuels are the accumulation of solar energy over millions and millions of years. Renewable fuels are the accumulation of energy over a few months. It's not so simple to simply grow our way out of this problem. The fact is that even with biofuels, the human race is going to be in for a rude awakening with regards to its energy consumption.
4. MAC address ARE NOT UNIQUE! They are nearly unique, but if you operate under the idea that mac addresses are unique then your life will be hell when you have to track down a duplicate MAC on a large enterprise network because you believe it cannot happen. It does, although infrequently, and it makes networking very very 'interesting' when it happens.
I've always wondered how prevalent this is. The most significant 24bits are the vendor ID and the least significant are "supposed" to be unique within that vendor. Larger vendors have more then one vendor ID. So does a large NIC manufacturer reuse those lower 24 bits frequently? You can do a lookup for vendor IDs here: http://coffer.com/mac_find/
Had ~3000 Dell PCs on an enterprise network. Our routers were having a problem because the Broadcom chips we were using hash the layer 2 table index based on the SA and VLAN. Buckets were 8 entries deep. Well, take ~3000 MACs with the same upper 24 bits and we had conflicts. Even though the MSBs were the same, don't remember seeing the LSBs repeating. Of course 3000 is easy to randomly fit into ~16 million.
Very interesting. Just a couple weeks ago NPR had an interview with three doctors about how the body's inflammation response is turning out to play a much larger role in diseases then previously thought. link
An Ethernet header is 18 bytes. Don't forget the 4 byte footer for CRC
Ok, that sounded lame. I should have just said, 'Don't forget the 4 byte footer for CRC for the Ethernet encapsulation'
Ethernet header = 14 bytes
IP header = 20 bytes
TCP Header = 20 bytes
An Ethernet header is 18 bytes. Don't forget the 4 byte footer for CRC.
Let them invent something that will lást a decade, instead of break down after two or three years. Wait, didn't they already build fridges, washing-machines and T.V.-s that would last that long in the seventies? Gee, I wonder what happened to technology. O yes, I know, they improved it...
There really is something to be said to the old adage, "They don't make 'em like they used to."
I have a 33 year old Kenmore refrigerator/freezer that my father gave me. It's older then myself. Still going strong. Going to get something newer that looks nicer and is more efficient but I don't think it'll last half as long.
And what about furniture? I can go to Goodwill and find old wood furniture that's better made then much of what you can buy new today, except for the more expensive stuff. Things like dressers with drawers that are held together with dovetail joints. Sure, it's finish is pitted and beaten, but you can strip the varnish down and sand the top. Then either oil it or revarnish it and it'll look beautiful. For someone starting off furnishing their first pad I recommend this over going to Ikea if they don't mind using some elbow grease.
The quote reminds me of my younger years when I had to... um... quickly dry things I grew before they rotted.
Take a tupperware container. Wedge two layers of chicken wire, with a few inches between the bottom, middle, and top. On the bottom layer of wire
put a cotton cloth with Damp Rid(Potassium Chloride). Put the items you want to dehydrate on the top layer. Seal up. The salt will leech the water out and
when it saturates, dump it at the bottom of the container.
So given a big enough contraption to hold enough salt with a large enough surface area, a way to move enough air over it(fan), and a way to get the water out and stored(pump), could you
collect 600 gallons of a water a day in a desert?