The frequency of reallocations issue is orthogonal to the slop (measurable or unmeasurable) one. Anything that your allocation strategy does will cause on average as much excess slop (by pushing allocations into a bigger band) as it reduces slop (by being closer to the limit of the band).
There is nothing intrinsic about powers of 2 that makes allocators significantly more efficient. See recent comp.lang.c discussions (last 2 weeks) about the superstitions which surrounds powers of 2, and their debunking. (Or just look in the commit history for the linux kernel for the kcache pool implementation)
Indeed, and it's certainly one that they've made almost no attempt to live up to for well over half a decade. I seem to remember the first time I called google evil was back in the early noughties, when it became clear they had no intention to deliver on their promises regarding the buyout of dejanews and acquisition of other usenet archives, and provided a thoroughly inferior service. (So much so, that I take almost every opportunity possible to say googlegroups sucks now.)
See page 27 of the PDF. He explains that the allocator, jemalloc, rounds up some allocation requests to easier to handle size. He calls this wastage "slop". Then look at the final point on that page - in order to reduce slop, always allocate a power of two sized block, as those never have slop.
So in order to stop the allocator wasting memory by using up more memory than requested, we're supposed to ask for more memory than we need? That seems to be a facepalm moment. Let's move wastage to where we can't measure it, so that we can't see any wastage any more. The bind moggles.
Hmm, w3m pulls up, for example, cnn.com's front page and uses only 7MB in total, and that includes all images. The content of that page summed to 440KB. Firefox (version old.old) seems to gobble up 200MB for the same page. Personally, I do think that is unreasonable (and 250MB is even worse).
People are spoiled by having RAM come out of their ears, and don't realise how much wastage and bloat there really is.
However, I also don't trust the Firefox developers because after several years of being accused of being memory hogs, and every single time staunchly denying it, brushing off such issues by saying they were "features" like "caching", they finally admitted they were in the wrong. When you've lied so many times, why should anyone trust you any more?
Again, as from your perspective, that motivates me to perform my own checks. However, if they don't provide a ready-built linux/ppc64.deb with correct dependencies, I'm certainly not going to be bothered. "I've got a girlfriend and things to get done..."
13 of my keys have 3 symbols, and 1 has 4 symbols. My total will be different from yours. Mine will even differ from that of others in the same country as me, as we have 2 very different standard keyboard layouts for the two different linguistic groups in the country.
Where does the unstated *2 come from? Is that some US-centric there-are-only-two-symbols-per-key, the unshifted and the shifted, assumption which is inappropriate for 90% or more of the world? (Even the UK would typically have the pound sign, which isn't ASCII, as a shifted character, so the assumption doesn't even hold in the UK.) And why is a comment about security even focussing on one specific implementation of an input device anyway? The character set that's available to me when I use my N9 is different from that available to me on my workstation at home, his numbers, even if he can justify his arithmetic, are effectively meaningless.
""" The patent system has within it an underlying assumption; that your Better Mousetrap TM (pat pend) provides some degree of benefit that people are willing to pay for rather than steal. """
Quite the opposite. It assumes that people will want to steal it, and so provides you some protection if that happens. It says nothing about the legitimate licensing case, only about the stealing case.
""" Rossi could have ended almost all dispute by just running two eCats side-by-side, one with the catalyst and one without. Or even just one with the hydrogen and one without, where people picked the one getting the hydrogen. That would rule out many things. (Maybe not all, but a lot.) """
Total tosh. Let the two identical black boxes contain the following mechanism:
If(we got hydrogen) { use internal battery to output power } else { don't }
You've not proved that hydrogen is involved in the energy generation process at all. Rest was tl;dr.
It's hard to take seriously an article which contains remarks like the dumb: "26 letters, 10 numbers, 11 other character keys for a total of 94 characters" to the misleading: "Because hash functions like AES-256 only provide 2^256 possible unique outputs, collisions are obviously possible".
It also overlooks the fact that you're increasing your workload by a factor of X in order to increase the attacker's workload by a factor of X. Therefore there is precisely no leverage at all, and it's not really much of a win, that's a break even cost-wise.
The paragraph beginning "The advantage of bcrypt..." also seems to show that you don't appreciate the difference between a PRP like AES and a PRF like MD5 when it comes to collisions from iterated images. I'm not 100% sure about the logic you're using to lead to the "1000 possible values" claim either. If fact quite the opposite. Are you claiming that if MD5 were iteratd 2^160 times, there would be 2^160 such possible values? (I.e. every input would match a password stored in the rainbow tables.) Sounds bogus, in fact.
I'm a pointer, my g/f's a pointer, you're a pointer. Alas, the rest of the world are swipers.
As an ex-biker, and also as someone living in a cold climate, requiring gloves for several months of the year, usability with gloves is something I do value quite highly. I know it's been mentioned on talk.maemo.org several times, so it's not a completely unwanted feature. But while companies are doing their best to immitate Apple (the N9 has been called the iPhoney and the iClone by some), everyone's swipey all the way from now on.
The news stories about Elop pulling the plug weren't exageration. There literally will be nothing left of Maemo/MeeGo 6 months time. I'm hoping that as much gets opened as possible so that the hobbyists can get the most out of what they've bought, and similarly can port as much to other hardware platforms. Unfortunately, for various reasons, some of the core components will never be opened (I presume things like BME, MCE, and DSME, I've not checked the public repo's recently), which will make porting harder, but not impossible.
I'm glad to see that the N900 still has such popularity overseas (it was DAMN popular in Finland). I hope you like the resistive touchscreen on it - I was one of the hackers on the tsc2005 driver, amongst other things;-)
That does look like a nice active mailing list. I'll scan back through the archives and see if I can see relevant threads. Not seeing any speed-related comments jump out implies I shouldn't fret about it.
I work for Nokia, but I didn't get the N950 because of that - my g/f independently applied for the developer unit, and we are lucky enough to live in a country which was undersubscribed (not strictly true - it was oversubscribed initially, but they had a recall for low level reflashing, and some people didn't want their devices back, and we were at the top of the reserve list). So technically, it's my g/f's N950. Well, technically it's Nokia's, but I'm hoping they forget about it.
As I work for Nokia, and the N9 project is approaching maintenance phase, there has of course been a request by management for feedback on the whole project. Clearly I can't repeat what I actually wrote, but I can assure you I made sure they knew that opinions like yours were common, and that I wasn't exactly happy about that.
Based on the "Made in Finland" labels, and the fact that I know which production line in Finland they came off. I even know the sources of the chips which have nothing printed on them (but there's nothing exciting there). This I know because these particular devices are my ${DAYJOB}.
Presumably Nokia gets the large runs of cheap Symbian phones from foxconn. But that's irrelevant, as the challenge was "Find me a computer", not "Find me a company". I've found 3.
Nobody. That's why I explicitly mentioned that all inter-process control messages can be sniffed on the dbus busses, were any back-door to be in userspace. And why I mentioned that if it requires communication with the modem chip, then you can sniff that communication too using your own kernel, just patch the McSAAB driver.
> Finally - who's to really say that there isn't one hiding in Android?
Not me, haven't addressed Android at all. I wonder if you actually read my post, it seems you've paid no attention to any of it. I only made a comment about one of Nokia's platforms, as the finger was still being pointed at Nokia.
You're gibbering. C's "const*" is as much memory protection as "private", more so, it anything. In particular as private isn't there for memory protection/per se/, it's for encapsulation. Your public functions can nuke all concepts of memory protection, therefore your private methods provided no actual protection.
I don't know anything about Obj-C, but I do know that C++ is C++ done wrong. I just hope that the people who ruined C++ don't move into other languages and ruin them too. I'm particularly worried about Digital Mars D, which used to be a great language (it was also a C++ done right), but now A.A. has started contributing to it, it could just turn into another bombsite.
I've long considered trying out LUA for some semi-serious home projects - in particular for a website. That would involve a fair amount of string processing, so you've made me nervous. A quick search for ``lua string processing slow'' didn't yield anything particularly informative - can you provide some pointers to where the issue is discussed, so that I can arm myself better before committing.
"I was excited at the idea of a DRM-free music store outside the US, but the only one I can find is iTunes "
Where were you during the *original* mp3.com, before it was bulldozed and reinvented by the MAFIAA? CDBaby has mp3 sales too. And if you're not willing to ask questions, there are a dozen in Russia which let you pay by SMS. There literally is no shortage of such sites.
All of this goes back more than 10 years, way before iTunes was popular.
Well, I can assure you that at the kernel level, Nokia's linux phones have no such back doors in. You don't have to take my word for it, I'm only the gatekeeper who vets every patch that gets included in the kernel, you can freely grab the source and diff it against upstream and check for yourself.
Of course, there would be ways of adding back doors to the phone subsystem which is a separate core running its own OS. But all communication to the modem goes via the AP, so you could easily modify our kernel and sniff all communication between userspace and modem.
Plenty of stuff in userspace is open source too, and again such claims can be easily disproved. Even if you don't have the source, most of the inter process communication is via dbus, all of that can be sniffed trivially.
Were there really to be backdoors in Nokia's linux phones, then it would be trivial to point to the actual source code, or show traces where it happens. The lack of such evidence highlights the emptiness of the claims.
Pretty sure my Nokia N900 and N9 (consumer version) weren't. My N950 (developer edition) wasn't either, but that was from a small run, and might be considered a prototype.
A handy hint for finding counter-examples is looking for companies who still maintain their own manufacturing facilities. A lot of the new kids on the block have never had such facilities, they're clearly more likely to be customers of foxconn and their ilk.
Slashdot Mirror
Getting your balls groped in public is not an erosion of our rights with a straight face.
Getting your balls groped in public is an erosion of our rights with a shocked face.
The frequency of reallocations issue is orthogonal to the slop (measurable or unmeasurable) one. Anything that your allocation strategy does will cause on average as much excess slop (by pushing allocations into a bigger band) as it reduces slop (by being closer to the limit of the band).
There is nothing intrinsic about powers of 2 that makes allocators significantly more efficient. See recent comp.lang.c discussions (last 2 weeks) about the superstitions which surrounds powers of 2, and their debunking. (Or just look in the commit history for the linux kernel for the kcache pool implementation)
Indeed, and it's certainly one that they've made almost no attempt to live up to for well over half a decade. I seem to remember the first time I called google evil was back in the early noughties, when it became clear they had no intention to deliver on their promises regarding the buyout of dejanews and acquisition of other usenet archives, and provided a thoroughly inferior service. (So much so, that I take almost every opportunity possible to say googlegroups sucks now.)
You "rein in", not "reign in". As in what you horses.
See page 27 of the PDF. He explains that the allocator, jemalloc, rounds up some allocation requests to easier to handle size. He calls this wastage "slop". Then look at the final point on that page - in order to reduce slop, always allocate a power of two sized block, as those never have slop.
So in order to stop the allocator wasting memory by using up more memory than requested, we're supposed to ask for more memory than we need? That seems to be a facepalm moment. Let's move wastage to where we can't measure it, so that we can't see any wastage any more. The bind moggles.
Hmm, w3m pulls up, for example, cnn.com's front page and uses only 7MB in total, and that includes all images. The content of that page summed to 440KB. Firefox (version old.old) seems to gobble up 200MB for the same page. Personally, I do think that is unreasonable (and 250MB is even worse).
People are spoiled by having RAM come out of their ears, and don't realise how much wastage and bloat there really is.
However, I also don't trust the Firefox developers because after several years of being accused of being memory hogs, and every single time staunchly denying it, brushing off such issues by saying they were "features" like "caching", they finally admitted they were in the wrong. When you've lied so many times, why should anyone trust you any more?
.deb with correct dependencies, I'm certainly not going to be bothered. "I've got a girlfriend and things to get done..."
Again, as from your perspective, that motivates me to perform my own checks. However, if they don't provide a ready-built linux/ppc64
"Look at your keyboard and count them."
13 of my keys have 3 symbols, and 1 has 4 symbols. My total will be different from yours. Mine will even differ from that of others in the same country as me, as we have 2 very different standard keyboard layouts for the two different linguistic groups in the country.
Where does the unstated *2 come from? Is that some US-centric there-are-only-two-symbols-per-key, the unshifted and the shifted, assumption which is inappropriate for 90% or more of the world? (Even the UK would typically have the pound sign, which isn't ASCII, as a shifted character, so the assumption doesn't even hold in the UK.) And why is a comment about security even focussing on one specific implementation of an input device anyway? The character set that's available to me when I use my N9 is different from that available to me on my workstation at home, his numbers, even if he can justify his arithmetic, are effectively meaningless.
"""
The patent system has within it an underlying assumption; that your Better Mousetrap TM (pat pend) provides some degree of benefit that people are willing to pay for rather than steal.
"""
Quite the opposite. It assumes that people will want to steal it, and so provides you some protection if that happens. It says nothing about the legitimate licensing case, only about the stealing case.
"""
Rossi could have ended almost all dispute by just running two eCats side-by-side, one with the catalyst and one without. Or even just one with the hydrogen and one without, where people picked the one getting the hydrogen. That would rule out many things. (Maybe not all, but a lot.)
"""
Total tosh. Let the two identical black boxes contain the following mechanism:
If(we got hydrogen) { use internal battery to output power }
else { don't }
You've not proved that hydrogen is involved in the energy generation process at all. Rest was tl;dr.
It's hard to take seriously an article which contains remarks like the dumb:
"26 letters, 10 numbers, 11 other character keys for a total of 94 characters"
to the misleading:
"Because hash functions like AES-256 only provide 2^256 possible unique outputs, collisions are obviously possible".
It also overlooks the fact that you're increasing your workload by a factor of X in order to increase the attacker's workload by a factor of X. Therefore there is precisely no leverage at all, and it's not really much of a win, that's a break even cost-wise.
The paragraph beginning "The advantage of bcrypt..." also seems to show that you don't appreciate the difference between a PRP like AES and a PRF like MD5 when it comes to collisions from iterated images. I'm not 100% sure about the logic you're using to lead to the "1000 possible values" claim either. If fact quite the opposite. Are you claiming that if MD5 were iteratd 2^160 times, there would be 2^160 such possible values? (I.e. every input would match a password stored in the rainbow tables.) Sounds bogus, in fact.
I'm a pointer, my g/f's a pointer, you're a pointer. Alas, the rest of the world are swipers.
As an ex-biker, and also as someone living in a cold climate, requiring gloves for several months of the year, usability with gloves is something I do value quite highly. I know it's been mentioned on talk.maemo.org several times, so it's not a completely unwanted feature. But while companies are doing their best to immitate Apple (the N9 has been called the iPhoney and the iClone by some), everyone's swipey all the way from now on.
Making less shit is still improving.
The news stories about Elop pulling the plug weren't exageration. There literally will be nothing left of Maemo/MeeGo 6 months time. I'm hoping that as much gets opened as possible so that the hobbyists can get the most out of what they've bought, and similarly can port as much to other hardware platforms. Unfortunately, for various reasons, some of the core components will never be opened (I presume things like BME, MCE, and DSME, I've not checked the public repo's recently), which will make porting harder, but not impossible.
;-)
I'm glad to see that the N900 still has such popularity overseas (it was DAMN popular in Finland). I hope you like the resistive touchscreen on it - I was one of the hackers on the tsc2005 driver, amongst other things
That does look like a nice active mailing list. I'll scan back through the archives and see if I can see relevant threads. Not seeing any speed-related comments jump out implies I shouldn't fret about it.
I work for Nokia, but I didn't get the N950 because of that - my g/f independently applied for the developer unit, and we are lucky enough to live in a country which was undersubscribed (not strictly true - it was oversubscribed initially, but they had a recall for low level reflashing, and some people didn't want their devices back, and we were at the top of the reserve list). So technically, it's my g/f's N950. Well, technically it's Nokia's, but I'm hoping they forget about it.
As I work for Nokia, and the N9 project is approaching maintenance phase, there has of course been a request by management for feedback on the whole project. Clearly I can't repeat what I actually wrote, but I can assure you I made sure they knew that opinions like yours were common, and that I wasn't exactly happy about that.
Based on the "Made in Finland" labels, and the fact that I know which production line in Finland they came off. I even know the sources of the chips which have nothing printed on them (but there's nothing exciting there). This I know because these particular devices are my ${DAYJOB}.
Presumably Nokia gets the large runs of cheap Symbian phones from foxconn. But that's irrelevant, as the challenge was "Find me a computer", not "Find me a company". I've found 3.
> Who said a backdoor had to be kernel level?
Nobody. That's why I explicitly mentioned that all inter-process control messages can be sniffed on the dbus busses, were any back-door to be in userspace. And why I mentioned that if it requires communication with the modem chip, then you can sniff that communication too using your own kernel, just patch the McSAAB driver.
> Finally - who's to really say that there isn't one hiding in Android?
Not me, haven't addressed Android at all. I wonder if you actually read my post, it seems you've paid no attention to any of it. I only made a comment about one of Nokia's platforms, as the finger was still being pointed at Nokia.
You're gibbering. C's "const*" is as much memory protection as "private", more so, it anything. In particular as private isn't there for memory protection /per se/, it's for encapsulation. Your public functions can nuke all concepts of memory protection, therefore your private methods provided no actual protection.
I don't know anything about Obj-C, but I do know that C++ is C++ done wrong. I just hope that the people who ruined C++ don't move into other languages and ruin them too. I'm particularly worried about Digital Mars D, which used to be a great language (it was also a C++ done right), but now A.A. has started contributing to it, it could just turn into another bombsite.
I've long considered trying out LUA for some semi-serious home projects - in particular for a website. That would involve a fair amount of string processing, so you've made me nervous. A quick search for ``lua string processing slow'' didn't yield anything particularly informative - can you provide some pointers to where the issue is discussed, so that I can arm myself better before committing.
"I was excited at the idea of a DRM-free music store outside the US, but the only one I can find is iTunes "
Where were you during the *original* mp3.com, before it was bulldozed and reinvented by the MAFIAA? CDBaby has mp3 sales too. And if you're not willing to ask questions, there are a dozen in Russia which let you pay by SMS. There literally is no shortage of such sites.
All of this goes back more than 10 years, way before iTunes was popular.
Get Orf Moi Lorn!!!!!
Well, I can assure you that at the kernel level, Nokia's linux phones have no such back doors in. You don't have to take my word for it, I'm only the gatekeeper who vets every patch that gets included in the kernel, you can freely grab the source and diff it against upstream and check for yourself.
Of course, there would be ways of adding back doors to the phone subsystem which is a separate core running its own OS. But all communication to the modem goes via the AP, so you could easily modify our kernel and sniff all communication between userspace and modem.
Plenty of stuff in userspace is open source too, and again such claims can be easily disproved. Even if you don't have the source, most of the inter process communication is via dbus, all of that can be sniffed trivially.
Were there really to be backdoors in Nokia's linux phones, then it would be trivial to point to the actual source code, or show traces where it happens. The lack of such evidence highlights the emptiness of the claims.
Pretty sure my Nokia N900 and N9 (consumer version) weren't.
My N950 (developer edition) wasn't either, but that was from a small run, and might be considered a prototype.
A handy hint for finding counter-examples is looking for companies who still maintain their own manufacturing facilities. A lot of the new kids on the block have never had such facilities, they're clearly more likely to be customers of foxconn and their ilk.