The fact I cannot get used to it means either my brain is off or MS made a bad decision. This being/., you can probably figure out which I think it is.
Go ahead, but I strongly suspect you're in small company. If you ask me, the search box is the best thing MS has done with the Windows GUI since the addition of the quick launch icons back in the 95/98 era. It's significantly better than what you get with any of the Linux UIs except KDE. (I'm assuming it's possible to get that set up right, though I haven't bothered. I'm also talking from the point of view of launching GUI programs, not stuff that you'd be running in a console anyway.)
(And don't read that as "it's the least bad of a poor lot" either.)
The only mains-powered clocks I've seen that use the power frequency as their frequency source tend to be older ones. Perhaps there's some modern ones that use it, but I've not seen any.
The thinkgeek binary clock does, or at least did. My copy has a button that you have to hold down when you plug it in if your mains are 50 Hz instead of 60. (The thinkgeek page now says that it autosenses 50 or 60 hz.)
I think you're confusing presentation with the source data. If those five JPEGs are generated from a single light-field exposure, then the demo isn't faked. (Or at least, is faked to the same extent that a typical camera shot is faked because the sensor data needs to be processed before it's displayed to you.)
That's like how you described my statement: deceptive because it's got a kernel of truth.;-)
Most programs that people directly interact with make extensive uses of the heap. Out of 79 processes running on my Win7 box now (I think that even counts the idle process), 22 of them have over 10MB of private memory in their working set. 10 have over 25 MB, and Opera has over 1 GB.
The default max stack size with MSVC is 1 MB. Even if half of those process' memory are globals/statics, that means that they are holding several times as much memory in the heap as on the stack.
Basically what I'm saying is that even though most variables are on the stack, almost all programs that do interesting things (apart from some scientific code that uses statically-sized arrays) is going to do substantial heap work.
C++ users seldom use malloc, in my experience, it's always new. And even then, reference counted pointers are far more common than raw pointers these days. A reference counted pointer gives you almost as good a guarantee as a GC, other than cycles causing issues, and you get deterministic deletion making RAII possible as a benefit!
None of which has any applicability to what I said.
'new' has to do the same thing to allocate memory behind the scenes that 'malloc' does* (and is thus slower than a GC 'new'), and since even smart pointers "can't" move objects around, they don't do the same automatic locality-improving, heap-defragmenting behaviors that I said are subtle benefits of GCs.
If you want to get into how useful GCs are specifically, then talking about smart pointers is relevant, but aside from my final insinuation, I wasn't talking about that at all. (Even that last thing wasn't so much talking about GCs in terms of making it easier to manage memory so much as the practical relation between languages that are memory safe and the languages that have GCs.)
* It's very likely that your platform's 'new' is implemented in terms of malloc. (Or that 'malloc' is a thin wrapper around something else, and 'new' is implemented in terms of that.)
Here is part of 'new_op.cc' from GCC 4.6.0's distribution:
They other problem was that something set them off on a wrong trail, so they weren't even looking for a memory corruption bug. If they had Valgrind available, I'm not sure they would have used it.
The allocation/deallocation advantages that GC languages have can be given to C++ through techniques such as memory pools.
If you know the sizes of the objects you'll be allocating in advance (you don't always) and the library you're using allows it, and if a few other things work out. As it so happens this often is the case, but it isn't always.
I'm just pointing out that a GC language should never be faster than optimised C or C++. Google's test demonstrates that.
Sure, but that's somewhat of a given in the sense that you can make C "fake" everything that Java does behind the scenes. If you found some situation where Java's JIT was giving a performance boost, you could go and write a JIT and JIT your C code.
And there are programs & inputs where you won't be able to avoid fragmentation short of relocating existing objects and fixing up pointers (i.e. what a copying GC does anyway).
If you know and understand computers, c++ is fairly easy as it doesnt obfuscate things the way java does.
Hmm, to be honest, there's one part of both of those languages that I don't have a good idea how to implement, and that's exceptions. (Hey, that's in both languages!)
pros should know their c.
They should. That doesn't mean they should use it.
The part where I agree is that I think that leaks can be overrated. Smart pointers take care of a lot of those problems, as you say, and even if they arise, they're often not a big deal. (So I restart my web browser every few days. It saves my tabs. Big whoop. Would be nice if I didn't have to do that, but that's not going to be what I base my "what software do I use" decisions on. 'couse for some high-availability web server, this would be disastrous.)
The place where I disagree is when you look at other aspects of memory safety. When you look at all the stereotypical memory safety errors, they're often just about the hardest single-threaded bugs to track down. I diagnosed a use-after-free bug just a few days ago. I happened to get lucky and spotted it after 5 or 10 minutes because I happened to look at the right pointer values, but that was after a couple other people I think had spent many hours on it. And that's just talking bugs, not even getting into the whole class of security vulnerabilities that memory-safe languages eliminate.
(Technically saying your language is memory-safe is different from saying it has a GC, but since memory safety is basically a prerequisite for having a decent garbage collector, in practice they go hand-in-hand. )
Just for future reference, not everything I say is necessarily applicable in every situation. For instance, Java does not run very fast at all on my abacus. It would also be possible to craft some programs where the Java version would exhibit pathologically bad behavior and/or the C++ version would behave particularly well, and the consequences of GCs moving things around wouldn't be a big deal.
If you did a lot of string manipulation, pascal would come out a lot faster. (because, for example, it knows the length of strings without having to crawl them looking for null bytes and such).
I like Pascal strings as much as the next guy and think it's rather better than the C model, but it's not like you can't track lengths yourself and eliminate that performance difference.
BTW, one subtle difference between C and C++ is in templates. Templates can reveal a lot more information to the compiler. The classic example here (which is probably an unusual case, but whatever) is std::sort in vs qsort from stdlib.h; std::sort typically blows qsort out of the water because it can do way more inlining.
A GC is a net loss, but don't think it doesn't have good effects mixed in there. Allocation of memory is a few instructions with a GC; malloc() can't hope to be in that same league. On a whole, GCs improve the memory locality of your program as it runs, with some substantial hiccups at the collections; manual memory management hinders it as your heap becomes more fragmented.
On a whole I think most programs nowadays should be written in a managed language; the performance gap just doesn't matter for most things.
IIRC, my old "moderately secure" password (used for my two university logins) took over 50% more button/screen presses to enter on my N900 than a normal keyboard.
That's only five attempts every five minutes or one attempt per minute allowed.
Let's look at some alternate math, considering that the article is talking about offline lookup.
3.3 billion passwords/sec decreases your estimate by a factor of 198 billion (basically 2^11). That gives 0.1 years. Not so attractive to break your/. password, but if you suspect someone has a fair bit of money in their bank account, easily worth it for that.
Of course, we all know that all networks are secure and so no one could ever get their hands on a list of password hashes, right?
Turn off some new stuff in the options somewhere to go back to a mostly older page and it'll give you it back. I didn't even realize it was gone for most people.
I said that sort of in jest (though I think I'd do almost anything to get out of an office of someone who had one of those), and I have heard the feel is really good.
That being said, I don't really have a problem with many "normal" keyboards; I've typed this whole post using my 4-year-old MS Natural 4000 with no changes, with my eyes closed during the entire process. Opening them now I see there's an extraneous space where I made an edit without knowing exactly what would happen; I think I'll leave it.
Slashdot Mirror
The fact I cannot get used to it means either my brain is off or MS made a bad decision. This being /., you can probably figure out which I think it is.
Go ahead, but I strongly suspect you're in small company. If you ask me, the search box is the best thing MS has done with the Windows GUI since the addition of the quick launch icons back in the 95/98 era. It's significantly better than what you get with any of the Linux UIs except KDE. (I'm assuming it's possible to get that set up right, though I haven't bothered. I'm also talking from the point of view of launching GUI programs, not stuff that you'd be running in a console anyway.)
(And don't read that as "it's the least bad of a poor lot" either.)
Oh, now that I read the rest of his comment, adolph beat me to the punch. Oh well.
It's fantastic, even the keyboard is useless.
That's not true at all! You still get SysRq!
The only mains-powered clocks I've seen that use the power frequency as their frequency source tend to be older ones. Perhaps there's some modern ones that use it, but I've not seen any.
The thinkgeek binary clock does, or at least did. My copy has a button that you have to hold down when you plug it in if your mains are 50 Hz instead of 60. (The thinkgeek page now says that it autosenses 50 or 60 hz.)
I think you're confusing presentation with the source data. If those five JPEGs are generated from a single light-field exposure, then the demo isn't faked. (Or at least, is faked to the same extent that a typical camera shot is faked because the sensor data needs to be processed before it's displayed to you.)
To get the same effect you'd have to replace malloc entirely. Then you'd have to be able to relocate existing objects and patch up pointers.
You can do it in C, but you'd not be using malloc except, perhaps, for the initial allocation.
That's like how you described my statement: deceptive because it's got a kernel of truth. ;-)
Most programs that people directly interact with make extensive uses of the heap. Out of 79 processes running on my Win7 box now (I think that even counts the idle process), 22 of them have over 10MB of private memory in their working set. 10 have over 25 MB, and Opera has over 1 GB.
The default max stack size with MSVC is 1 MB. Even if half of those process' memory are globals/statics, that means that they are holding several times as much memory in the heap as on the stack.
Basically what I'm saying is that even though most variables are on the stack, almost all programs that do interesting things (apart from some scientific code that uses statically-sized arrays) is going to do substantial heap work.
That's sort of why I put it in quotes. But you're right; "mimic" would be closer, or even just "do something similar as". :-)
C++ users seldom use malloc, in my experience, it's always new. And even then, reference counted pointers are far more common than raw pointers these days. A reference counted pointer gives you almost as good a guarantee as a GC, other than cycles causing issues, and you get deterministic deletion making RAII possible as a benefit!
None of which has any applicability to what I said.
'new' has to do the same thing to allocate memory behind the scenes that 'malloc' does* (and is thus slower than a GC 'new'), and since even smart pointers "can't" move objects around, they don't do the same automatic locality-improving, heap-defragmenting behaviors that I said are subtle benefits of GCs.
If you want to get into how useful GCs are specifically, then talking about smart pointers is relevant, but aside from my final insinuation, I wasn't talking about that at all. (Even that last thing wasn't so much talking about GCs in terms of making it easier to manage memory so much as the practical relation between languages that are memory safe and the languages that have GCs.)
* It's very likely that your platform's 'new' is implemented in terms of malloc. (Or that 'malloc' is a thin wrapper around something else, and 'new' is implemented in terms of that.)
Here is part of 'new_op.cc' from GCC 4.6.0's distribution:
See this reply (and my followup).
They other problem was that something set them off on a wrong trail, so they weren't even looking for a memory corruption bug. If they had Valgrind available, I'm not sure they would have used it.
The allocation/deallocation advantages that GC languages have can be given to C++ through techniques such as memory pools.
If you know the sizes of the objects you'll be allocating in advance (you don't always) and the library you're using allows it, and if a few other things work out. As it so happens this often is the case, but it isn't always.
I'm just pointing out that a GC language should never be faster than optimised C or C++. Google's test demonstrates that.
Sure, but that's somewhat of a given in the sense that you can make C "fake" everything that Java does behind the scenes. If you found some situation where Java's JIT was giving a performance boost, you could go and write a JIT and JIT your C code.
Part of our code base is Windows-only; that was part of it. (Fortunately this is becoming less of an issue.)
We've made an attempt at using Purify on Windows but that didn't go very well... I forget what the issue was.
"On the whole."
And there are programs & inputs where you won't be able to avoid fragmentation short of relocating existing objects and fixing up pointers (i.e. what a copying GC does anyway).
If you know and understand computers, c++ is fairly easy as it doesnt obfuscate things the way java does.
Hmm, to be honest, there's one part of both of those languages that I don't have a good idea how to implement, and that's exceptions. (Hey, that's in both languages!)
pros should know their c.
They should. That doesn't mean they should use it.
I sort of agree and sort of don't.
The part where I agree is that I think that leaks can be overrated. Smart pointers take care of a lot of those problems, as you say, and even if they arise, they're often not a big deal. (So I restart my web browser every few days. It saves my tabs. Big whoop. Would be nice if I didn't have to do that, but that's not going to be what I base my "what software do I use" decisions on. 'couse for some high-availability web server, this would be disastrous.)
The place where I disagree is when you look at other aspects of memory safety. When you look at all the stereotypical memory safety errors, they're often just about the hardest single-threaded bugs to track down. I diagnosed a use-after-free bug just a few days ago. I happened to get lucky and spotted it after 5 or 10 minutes because I happened to look at the right pointer values, but that was after a couple other people I think had spent many hours on it. And that's just talking bugs, not even getting into the whole class of security vulnerabilities that memory-safe languages eliminate.
(Technically saying your language is memory-safe is different from saying it has a GC, but since memory safety is basically a prerequisite for having a decent garbage collector, in practice they go hand-in-hand. )
Just for future reference, not everything I say is necessarily applicable in every situation. For instance, Java does not run very fast at all on my abacus. It would also be possible to craft some programs where the Java version would exhibit pathologically bad behavior and/or the C++ version would behave particularly well, and the consequences of GCs moving things around wouldn't be a big deal.
If you did a lot of string manipulation, pascal would come out a lot faster. (because, for example, it knows the length of strings without having to crawl them looking for null bytes and such).
I like Pascal strings as much as the next guy and think it's rather better than the C model, but it's not like you can't track lengths yourself and eliminate that performance difference.
BTW, one subtle difference between C and C++ is in templates. Templates can reveal a lot more information to the compiler. The classic example here (which is probably an unusual case, but whatever) is std::sort in vs qsort from stdlib.h; std::sort typically blows qsort out of the water because it can do way more inlining.
A GC is a net loss, but don't think it doesn't have good effects mixed in there. Allocation of memory is a few instructions with a GC; malloc() can't hope to be in that same league. On a whole, GCs improve the memory locality of your program as it runs, with some substantial hiccups at the collections; manual memory management hinders it as your heap becomes more fragmented.
On a whole I think most programs nowadays should be written in a managed language; the performance gap just doesn't matter for most things.
IIRC, my old "moderately secure" password (used for my two university logins) took over 50% more button/screen presses to enter on my N900 than a normal keyboard.
That's only five attempts every five minutes or one attempt per minute allowed.
Let's look at some alternate math, considering that the article is talking about offline lookup.
3.3 billion passwords/sec decreases your estimate by a factor of 198 billion (basically 2^11). That gives 0.1 years. Not so attractive to break your /. password, but if you suspect someone has a fair bit of money in their bank account, easily worth it for that.
Of course, we all know that all networks are secure and so no one could ever get their hands on a list of password hashes, right?
You do realize "Under this new versioning model, the next major release of the Linux kernel to follow will be Linux 3.1, then Linux 3.2, etc."
That's FTFA. So there will be a 3.1; in fact, it will likely be quite soon.
If you want rural coverage of 3G, that pretty much leaves out T-Mobile.
If you want any 3G with an iPhone, that leaves out T-mobile, at least if your iPhone works on the same frequencies as the US one.
Turn off some new stuff in the options somewhere to go back to a mostly older page and it'll give you it back. I didn't even realize it was gone for most people.
I said that sort of in jest (though I think I'd do almost anything to get out of an office of someone who had one of those), and I have heard the feel is really good.
That being said, I don't really have a problem with many "normal" keyboards; I've typed this whole post using my 4-year-old MS Natural 4000 with no changes, with my eyes closed during the entire process. Opening them now I see there's an extraneous space where I made an edit without knowing exactly what would happen; I think I'll leave it.