Changing numbers just to change numbers is a waste of time. The reasoning Linus gives for the change is absolutely worthless. He can't count to 40. what!? Where I work you would get fired for something like this.
This wastes everyones time and causes unnecessary confusion. If at least he said something like "It makes people talk about Linux" or "We wanted to celebrate our good work by tagging 3.0" I might have accepted the reasoning. I think the features between 2.6.40 and 3.0.0 have not earned the 3.0.0 badge.
What makes parallel programming hard is computer languages.
Most languages today are actually not designed for parallelism or concurrency simply because most computers for a very long time had only one core. This is why we have threading and locks everywhere. Threads have huge overhead from hundreds of kilobytes to megabytes. That may seem like nothing but ideally for parallelism and concurrency to work you need to be able to create thousands of processes at nearly no cost (hundreds of bytes each). And locks, don't even get me started with that!
Shared mutable state is also a major problem it makes parallelism very hard, again current languages make heavy use of it (Singletons).
Anyway, this problem has been solved ages ago just look into the Actor Model and Erlang to get started that should pretty much cover it.
Honestly, I think this is the worst reasoning I have ever heard. Calling it 2.8.0 instead of 2.6.41 because 41 is too big a number? Seriously!? In my mind 2.8.0 would mean a major redesign, a bit like the transition from 2.4 to 2.6. It sounds to me like this would simply be a 2.6.41 in disguise. Not worth changing the version unless major changes are made. How about a micro-kernel or some hard real-time Linus instead of wasting your time renaming things?
That is not the whole story.Telomeres control how many times a cell can divide. The more times a cell the divides the more likely it is to contain an accumulation of defects eventually leading to either the death of the cell triggered by MDM2 and P53 or if this fails an increased likelihood of cancer.
Simply increasing the counter of the number of times the cell can divide does not prevent cancer. In fact it could increase it! I would imagine that cells with lots of defect will survive for longer instead of being replaced by cells that have not divided as many times leading to an overall increase in occurrences of cancer.
The ideal solution in my opinion would be to have a better control over this counter. P53 triggers cellular apoptosis (cell death) when telomeres run out. MDM2 triggers cellular apoptosis if P53 stops functioning. However if both mechanisms fail there is a high likelihood of cancer since these damaged cells can divide indefinitely. What would be more interesting is adding a new monitor X what would monitor MDM2 or P53 and add extra redundancy. Effectively changing the likelihood of getting cancer. Once this is done perhaps telomere extensions could make sense.
This is interesting. I wonder what the implications for the drake equation are.
If life evolved twice independently on earth I would think that life in the universe is quite common. Time will tell if this is indeed the case.
On the other hand if life did not evolve twice independently. Wouldn't this mean that if life branched at a very early stage theories like panspermia are less likely?
Why? We dont need this. We need a Storm 3 that WORKS! Why is RIM ignoring the market that made them successful? Let Apple have the consumers, let Droid have the geeks. Business needs a phone that just works, dammit. Oooh, a tablet. I can read my email with larger fonts? WTF?!?!?
Hey RIM, pssst! There is nothing wrong with having the boring, but secure, reliable but quick, phone that just works. NOTHING.
You are being distracted into oblivion by people who WONT BUY YOUR TABLET ANYWAY.
It's likely that the QNX team (recently acquired by RIM) will be making this product. So I don't think it will change the focus and quality of the current offerings.
I really don't like it when I hear someone say to avoid overengineering. Of course by-definition over-engineering is bad, but this is generally bad advice. Back when I started doing software engineering out of college I admit I did some over-engineering. When you have someone inexperienced but passionate about software this will happen on occasion. My advice is, don't worry about it, it will pass in time.
However, despite running into over-engineered solutions on occasion, I don't really mind them. The worst code I have seen was done by people in the name of avoiding overengineering. Although I have seen them, overengineered solutions are so much less frequent than underengineered solutions. Also they generally work. I can handle maintaining them as I can slowly simplify it as I work. Usually there is a bit of a learning curve but once handled it can be easy to work with.
It is much harder when the design is too simple to handle the requirements. I have to add full error handing and support usage scenarios that the software wasn't designed for but was expected that it had been. It usually needs to be almost entirely rewritten because it wasn't modular or flexible at all. This type of code also tends to be "optimized" by using normally bad coding practices which the author thinks will make the code faster but didn't actually bother to check.
So sure, avoid overengineering but don't avoid it too much. It is like economics with inflation and deflation. Both can be bad but a little inflation to avoid deflation isn't a big deal.
Avoid over-engineering and avoid no engineering is what it comes down to.
I strongly disagree with "2. Functions and methods should be as small as possible. You should make it an obsession to split methods and functions into the smallest possible components."
I figure that an extra STATEMENT adds a bit of extra work for the person who maintains your code to understand;
an extra FUNCTION adds about five times as much work since the control-flows into and out of it are now harder to understand;
and an extra CLASS adds four times as much work again to understand what it abstracts and how lifetime &c. work.
So, every time you use a function for what could have been done with a statement, you're making your code harder to maintain.
In time you will learn that the alternative is worst. Even if it doesn't look like it at first.
Slashdot Mirror
...Sony used unix-based servers instead?
Yep.
Big List of Sony's Crimes
===================
- Totally sucking balls
No comment.
- Being an oppressive, money sucking super-organism
To be fair a business is there to make money.
- Crash Bandicoot
What?
- Installing rootkits and spyware on your computers, as a sadistic form of DRM
I have to agree that seems insanely unethical, disrespectful and criminal.
- Violating the GPL
Also illegal and insanely disrespectful to the people giving their work for free.
- Violating your mom
If my mom was writing GPL code or had Sony rootkits installed on her PC I would agree.
- http://en.wikipedia.org/wiki/List_of_Sony_Music_Entertainment_artists (With the exception of R.Kelly, clearly awesome dude)
No comment.
- Disc Read Error
Not relevant.
- Having a superior console
"Had" I think is the word you are looking for. Still having a BD player and Linux support did make it superior in my view at the time.
- Including OtherOS in the first place
Yes I agree with you 100%! They shouldn't remove features after a unit has been sold.
- Etc...
Ok so they don't want organizations to buy iPads for people!? Why?
You found some 2.6 compliant hardware?! Amazing! You mean like an HID mouse? You're probably right 2.6.40 probably doesn't HID devices anymore.
I was expecting something amazing for 3.0.0 like hard real-time and a micro-kernel. Never did I expect this crap from Linus.
Changing numbers just to change numbers is a waste of time. The reasoning Linus gives for the change is absolutely worthless. He can't count to 40. what!? Where I work you would get fired for something like this.
This wastes everyones time and causes unnecessary confusion. If at least he said something like "It makes people talk about Linux" or "We wanted to celebrate our good work by tagging 3.0" I might have accepted the reasoning. I think the features between 2.6.40 and 3.0.0 have not earned the 3.0.0 badge.
Vector clocks can prevent causality violations in concurrent systems.
What makes parallel programming hard is computer languages.
Most languages today are actually not designed for parallelism or concurrency simply because most computers for a very long time had only one core. This is why we have threading and locks everywhere. Threads have huge overhead from hundreds of kilobytes to megabytes. That may seem like nothing but ideally for parallelism and concurrency to work you need to be able to create thousands of processes at nearly no cost (hundreds of bytes each). And locks, don't even get me started with that!
Shared mutable state is also a major problem it makes parallelism very hard, again current languages make heavy use of it (Singletons).
Anyway, this problem has been solved ages ago just look into the Actor Model and Erlang to get started that should pretty much cover it.
Honestly, I think this is the worst reasoning I have ever heard. Calling it 2.8.0 instead of 2.6.41 because 41 is too big a number? Seriously!? In my mind 2.8.0 would mean a major redesign, a bit like the transition from 2.4 to 2.6. It sounds to me like this would simply be a 2.6.41 in disguise. Not worth changing the version unless major changes are made. How about a micro-kernel or some hard real-time Linus instead of wasting your time renaming things?
Eric
That is not the whole story.Telomeres control how many times a cell can divide. The more times a cell the divides the more likely it is to contain an accumulation of defects eventually leading to either the death of the cell triggered by MDM2 and P53 or if this fails an increased likelihood of cancer.
Simply increasing the counter of the number of times the cell can divide does not prevent cancer. In fact it could increase it! I would imagine that cells with lots of defect will survive for longer instead of being replaced by cells that have not divided as many times leading to an overall increase in occurrences of cancer.
The ideal solution in my opinion would be to have a better control over this counter. P53 triggers cellular apoptosis (cell death) when telomeres run out. MDM2 triggers cellular apoptosis if P53 stops functioning. However if both mechanisms fail there is a high likelihood of cancer since these damaged cells can divide indefinitely. What would be more interesting is adding a new monitor X what would monitor MDM2 or P53 and add extra redundancy. Effectively changing the likelihood of getting cancer. Once this is done perhaps telomere extensions could make sense.
This is interesting. I wonder what the implications for the drake equation are.
If life evolved twice independently on earth I would think that life in the universe is quite common. Time will tell if this is indeed the case.
On the other hand if life did not evolve twice independently. Wouldn't this mean that if life branched at a very early stage theories like panspermia are less likely?
Who on earth would want to save IPv4?
Carrier grade NAT is the dumbest idea yet. Just ditch the junk and move on.
Okay where do I signup to get a IPv6 address already?
Nobody seems ready and there is ~238 days to go...
Exactly! Plus you can only forward to a single machine for a given port number.
Oh, also NAT needs to keep a translation table meaning you can't establish large amounts of connections (think torrents).
Finally we will no longer have to use this IPv4 NAT garbage with all it's limitations!
Android will be more popular in the long run for one simple reason. Cost...
This is not really a surprise considering it is the only mainstream open platform not tied to any particular hardware.
In my mind this isn't really a RIM tablet. This is a QNX tablet made by the team who made the QNX operating system.
That RIM now owns QNX doesn't really change much in the short term. This is going to be awesome!
Why? We dont need this. We need a Storm 3 that WORKS! Why is RIM ignoring the market that made them successful? Let Apple have the consumers, let Droid have the geeks. Business needs a phone that just works, dammit. Oooh, a tablet. I can read my email with larger fonts? WTF?!?!?
Hey RIM, pssst! There is nothing wrong with having the boring, but secure, reliable but quick, phone that just works. NOTHING.
You are being distracted into oblivion by people who WONT BUY YOUR TABLET ANYWAY.
It's likely that the QNX team (recently acquired by RIM) will be making this product. So I don't think it will change the focus and quality of the current offerings.
A tablet with QNX sounds like a cool idea. From what I remember QNX is extremely fast and responsive.
I am not sure it will sell however.
In any case give me shell access and I'll buy one.
But if it makes you feel any better, Sony--yeah, you've "won."
Me not spending any money ever on a Sony product says otherwise.
I for one would buy a mod chip that would allow me to run Linux on my PS3.
Yes I honestly want to run Linux on my PS3 and I don't mind paying for games and movies.
I don't care too much for backups. But who knows it might eventually be useful when the console ages.
By the way homebrew as of today is not worth it in my opinion but things are getting better for example look at Alien Arena.
I really don't like it when I hear someone say to avoid overengineering. Of course by-definition over-engineering is bad, but this is generally bad advice. Back when I started doing software engineering out of college I admit I did some over-engineering. When you have someone inexperienced but passionate about software this will happen on occasion. My advice is, don't worry about it, it will pass in time.
However, despite running into over-engineered solutions on occasion, I don't really mind them. The worst code I have seen was done by people in the name of avoiding overengineering. Although I have seen them, overengineered solutions are so much less frequent than underengineered solutions. Also they generally work. I can handle maintaining them as I can slowly simplify it as I work. Usually there is a bit of a learning curve but once handled it can be easy to work with.
It is much harder when the design is too simple to handle the requirements. I have to add full error handing and support usage scenarios that the software wasn't designed for but was expected that it had been. It usually needs to be almost entirely rewritten because it wasn't modular or flexible at all. This type of code also tends to be "optimized" by using normally bad coding practices which the author thinks will make the code faster but didn't actually bother to check.
So sure, avoid overengineering but don't avoid it too much. It is like economics with inflation and deflation. Both can be bad but a little inflation to avoid deflation isn't a big deal.
Avoid over-engineering and avoid no engineering is what it comes down to.
I strongly disagree with "2. Functions and methods should be as small as possible. You should make it an obsession to split methods and functions into the smallest possible components."
I figure that an extra STATEMENT adds a bit of extra work for the person who maintains your code to understand;
an extra FUNCTION adds about five times as much work since the control-flows into and out of it are now harder to understand;
and an extra CLASS adds four times as much work again to understand what it abstracts and how lifetime &c. work.
So, every time you use a function for what could have been done with a statement, you're making your code harder to maintain.
In time you will learn that the alternative is worst. Even if it doesn't look like it at first.