Oh it parses it just fine. It was just a dumb idea to parse it in the first place.
Re-read the latest CVEs. There are bugs in the parsers that can be exploited, so even if you're never invoking the functions they're already run through the parser and the parser is breaking things for you.
On the open source projects I've worked on where Google is a big contributor, they are very keen to push features and randomly refactor large parts of code, but I've never seen them do anything like a security audit. They did, however, do a big audit of libavcodec (which they use) and fix around 300 security holes...
The second vulnerability is a lot harder to exploit. Most vulnerable things only allow attackers to set specific environment variables. If you can set arbitrary ones, then setting things like PATH or LD_LIBRARY_PATH (DYLD_LIBRARY_PATH on OS X) are already exploitable, at least for privilege escalation.
I've run all of the updates on OS X and I still got the vulnerable message. A couple of days after the bug was public and the patches were available, I grabbed the source from opensource.apple.com, applied the FSF patches (which required some manual intervention, as they didn't apply cleanly) and recompiled. I'm now running a patched bash that isn't vulnerable, but it's not the one that Apple supplied.
My whole family got really fed up very quickly after walking into a dark room, hitting the switch and having to stand there for 5 seconds until the light actually came on
I find this really hard to believe. I've been using CFLs exclusively for over 10 years - mostly buying cheap ones - and I've never seen one that takes more than about half a second to come on. The time taken to get to full brightness I can almost agree with (this was actually why I started using them originally - having a bedside light that took a couple of minutes to get to full brightness was nice) but in recent ones (i.e. ones from the last 4-5 years) the warm-up period has been 5-10 seconds, although growing to about 20 seconds after 3-4 years of use.
Let's do it again. The last set of CFLs I bought cost 50p each (the ones before that were 30p, but that was a special offer). According to my electricity bill, I pay a tiny fraction of a penny under 15p/kWh. That means that the bulb costs slightly more than 3kWh of electricity. It's a 15W bulb replacing a 60W one, so that's a 45W saving. Assuming that the incandescent is free, then it takes 75 hours of operation for it to save money. At 3 hours a day, that's 25 days. When I first did the arithmetic, the CFLs were 3-4 times more expensive, so it worked out at 3 months.
This is why I find the resistance to CFLs so hard to understand. It's saved me quite a bit of money over the last decade.
If you save more on energy, but spend a lot more on replacement bulbs, what is the break even point before it was a good investment?
When I did the arithmetic quite a few years ago, the break even point for CFLs was about 3 months. The bulbs I bought back then all lasted 6+ years. The cost of a CFL is around the cost of 3-10kWh, depending on the brand, so even if they incandescents were free you don't need the CFLs to last very long to break even.
Sounds like something's wrong with your wiring. I switched to using CFLs over a decade ago and the shortest lifetime I've had on one is 6 years (I think - one might have gone after 4). The first time I moved house, I brought a load with me, but they'd become so cheap that I didn't bother the last time. The only incandescents I've had last longer than a year are ones that are rarely used. I worked out that - back when they were expensive - that after 3 months of operation they'd saved me more in electricity than the cost of an equivalent incandescent, so they've been a pretty good investment.
I don't know why that's a surprise for you. Incandescents are also limited in terms of lifetime by being turned on and off. The thermal shock of taking a very thin wire filament from room temperature up to white hot in a fraction of a second is not very good for its lifetime. That's why lightbulbs are most likely to break when you turn them on.
Listening to users isn't necessarily a good thing. Henry Ford said that if he'd asked his customers what they wanted, they'd have asked for a faster horse. This is especially true of UI design, because most people (even power users) really don't measure what they're spending time doing and get into unproductive patterns. The problem with GNOME was that they also didn't listen to usability experts. Or even vaguely competent people who had read an HCI book. They went down a path of doing things that an uninformed user and a usability expert could both agree were stupid. Apparently they've improved recently, but it cost them a lot of users.
XP also tweaked the VM subsystem in a way that was quite noticeable if you had more than about 256MB of RAM (better performance), but the main feature it added was remote desktop (although only in the Pro version). I was quite tempted to upgrade from 2K for the remote desktop stuff.
I'm not a huge fan. The goal of D was to produce a better C++, but if you're designing a new language then C++ really isn't where I'd choose to start. It's not as bad as Ruby (I can't imagine the kind of person who would look at Smalltalk and say 'what this language really needs is Perl-like syntax'. Actually, I can't imagine the kind of person who'd say that about any language. Including Perl). Rust is probably the modern language that I like the most.
Not really. They've increased a bit above inflation, but the amount I'm spending on electricity has remained pretty constant, increasingly slightly below inflation (increases in device efficiency offsetting increase in costs). The amount I'm paying for gas has gone up a bit more.
I switched to DuckDuckGo and haven't looked back. They used to be noticeably worse in results quality, but Google has gone a long way downhill. Occasionally I don't find things with DDG and try Google. When I do, I have to wade through pages of totally irrelevant stuff to find that there are no matches, whereas at least DDG tells me straight away that it can only find half a dozen possibly-relevant things. I especially like the way DDG integrates with a number of domain-specific search engines.
I maintain the GNUstep / Clang Objective-C stack. Most people who use it now do so in Android applications. A lot of popular apps have a core in Objective-C with the Foundation framework (sometimes they use GNUstep's on Android, more often they'll use one of the proprietary versions that includes code from libFoundation, GNUstep and Cocotron, but they almost all use clang and the GNUstep Objective-C runtime). Amusingly, there are actually more devices deployed with my Objective-C stack than Apple's. The advantage for developers is that their core logic is portable everywhere, but the GUIs can be in Objective-C with UIKit on iOS or Java on Android (or, commonly for games, GLES with a little tiny bit of platform-specific setup code). I suspect that one of the big reasons why the app situation on Windows Phone sucks is that you can't do this with a Windows port.
It would be great for these people to have an open source Swift that integrated cleanly with open source Objective-C stacks. Let's not forget that that's exactly what Swift is: a higher-level language designed for dealing with Objective-C libraries (not specifically Apple libraries).
Objective-C is a good language for mid-1990s development. Swift looks like a nice language for early 2000s development. Hopefully someone will come up with a good language for late 2010s development soon...
It wasn't just about interface. People tend to forget how search engines did an absolutely horrible job of intelligently ranking the sites you wanted to see.
I find it pretty easy to remember - I go to Google today.
The UI was what made me switch both to Google originally and from it some years later. When I started using Google - and when Google started gaining significant market share - most users were on 56Kb/s or slower modem connections. AltaVista was the market leader and they'd put so much crap in their front page that it took 30 seconds to load (and then another 20 or so to show the results). Google loaded in 2-3 seconds. The AltaVista search results had to be a lot better to be faster. I switched away when they made the up and down arrow keys in their search box behave differently to every other text field in the system.
My 'precious electronic toys' use about a tenth of the power that the ones I was using a decade ago for the same purpose did. Even lighting power consumption has dropped. My fridge, freezer and washing machine are the big electricity consumers in my home - efficiency has improved there, but nowhere near as fast as for gadgets.
There's a lot more to government than military intelligence gathering and law enforcement (although it would be a good idea for someone to remind most current governments that those are two things, not one). And most government projects end up spending insane budgets. This isn't limited to the US. It amazes me how often government projects to build databases to store a few million records with a few tens to thousands of queries per second (i.e. the kind of workload that you could run with off-the-shelf software on a relatively low-spec server) end up costing millions. Even with someone designing a pretty web-based GUI, people paid to manually enter all of the data from existing paper records, and 10 years of off-site redundancy, I often can't see where the money could have gone. Large companies often manage to do the same sort of thing.
The one thing that the US does well in terms of tech spending is mandate that the big company that wins the project should subcontract a certain percentage to small businesses. A lot of tech startups have got their big breaks from this rule.
Add to that, about 10-20% of the population get motion sick using the kind of VR in Oculus Rift (myself included - I can use it for 2-5 minutes, depending on the mode). It's ludicrous to imagine building a school that would exclude 20% of the potential pupils on some random criterion. You might as well make schools that didn't let in gingers...
Apple already ships 64-bit ARM chips and a lot of other vendors are racing to do so. The Android manufacturers that I've spoken want 64-bit for the same reason that they want 8-core: It's a marketing checkbox and they don't want to be shipping a 32-bit handset when their competitor is marketing 64-bit as a must-have feature. ART is in the top 10 worst-written pieces of code I've had to deal with and is full of casts from pointers to int32_t (not even a typedef, let alone intptr_t), but it should get a 64-bit port soon.
64-bit is here for a while. A lot of modern '64-bit' CPUs only support 40-bit physical addresses, so are limited to 'only' 128GB of RAM. Most support 48-bit virtual addresses (the top bit is sign extended, so all 1 or all 0 depending on whether you've got a kernel or userspace address), limiting you to 'only' 32TB of virtual addresses. If RAM sizes continue to double once every year, then it takes another year to use each bit. We currently have some machines with 256GB of RAM, so are using 41 bits. 64 bits will last another 23 years. RAM increases have slowed a bit recently though. 10 years ago, you always wanted as much RAM as possible because you were probably swapping whatever you were doing. Now, most computers are happy with 2GB for programs and the rest for buffer cache. As SSDs get faster, there's less need for caching, but there might be more need for address space as people want to be able to memory map all the files that they access...
The real problem for Firefox is not the interface changes that people like you whine about, it's mobile. Now 30% of traffic is mobile and Firefox doesn't have an app for any Apple mobile devices and is effectively excluded from Android by Google's Microsoft-like illegal anti-competitive licensing deals with manufacturers (you can get the app, but it's not preloaded and only a few geeks ever would).
Huh? It's in the Google Play Market and is no harder to install than any other app. Once it's installed, the first time you click on a link from another app you're asked to choose the app that will handle links. I fall into the geek category (and so installed it from F-Droid, not Google Play), but found it trivial to switch to Firefox on the mobile. I mostly did because Chrome has spectacularly bad cookie management and I'd been trying to find a browser that did it better. Early Firefox ports were as bad, but now it's quite nice and with the Self Destructing Cookies add-on does exactly what I want.
The mobile is actually the only place I use Firefox...
I recall reading some years ago that there are two kinds of atheists:
Those that disbelieve all religions.
Those that disbelieve all except one religion.
For some reason, people in the second category describe themselves as 'religious'. And yet you'll be hard-pressed to find, for example, a Christian who requires the same standards of evidence for the non-existence of the Norse, Egyptian, Greek or Hindu gods as he requires that an atheist from the first category provides for the non-existence of the Abrahamic god.
How about 'tablet'? Coming through Heathrow security, I get told to take laptops, iPads, and Kindles out of my bag. I guess any brand of laptop has to come out, but tablets and ebook readers only do if they're made by Apple or Amazon...
Slashdot Mirror
Oh it parses it just fine. It was just a dumb idea to parse it in the first place.
Re-read the latest CVEs. There are bugs in the parsers that can be exploited, so even if you're never invoking the functions they're already run through the parser and the parser is breaking things for you.
On the open source projects I've worked on where Google is a big contributor, they are very keen to push features and randomly refactor large parts of code, but I've never seen them do anything like a security audit. They did, however, do a big audit of libavcodec (which they use) and fix around 300 security holes...
The second vulnerability is a lot harder to exploit. Most vulnerable things only allow attackers to set specific environment variables. If you can set arbitrary ones, then setting things like PATH or LD_LIBRARY_PATH (DYLD_LIBRARY_PATH on OS X) are already exploitable, at least for privilege escalation.
I've run all of the updates on OS X and I still got the vulnerable message. A couple of days after the bug was public and the patches were available, I grabbed the source from opensource.apple.com, applied the FSF patches (which required some manual intervention, as they didn't apply cleanly) and recompiled. I'm now running a patched bash that isn't vulnerable, but it's not the one that Apple supplied.
My whole family got really fed up very quickly after walking into a dark room, hitting the switch and having to stand there for 5 seconds until the light actually came on
I find this really hard to believe. I've been using CFLs exclusively for over 10 years - mostly buying cheap ones - and I've never seen one that takes more than about half a second to come on. The time taken to get to full brightness I can almost agree with (this was actually why I started using them originally - having a bedside light that took a couple of minutes to get to full brightness was nice) but in recent ones (i.e. ones from the last 4-5 years) the warm-up period has been 5-10 seconds, although growing to about 20 seconds after 3-4 years of use.
Let's do it again. The last set of CFLs I bought cost 50p each (the ones before that were 30p, but that was a special offer). According to my electricity bill, I pay a tiny fraction of a penny under 15p/kWh. That means that the bulb costs slightly more than 3kWh of electricity. It's a 15W bulb replacing a 60W one, so that's a 45W saving. Assuming that the incandescent is free, then it takes 75 hours of operation for it to save money. At 3 hours a day, that's 25 days. When I first did the arithmetic, the CFLs were 3-4 times more expensive, so it worked out at 3 months.
This is why I find the resistance to CFLs so hard to understand. It's saved me quite a bit of money over the last decade.
If you save more on energy, but spend a lot more on replacement bulbs, what is the break even point before it was a good investment?
When I did the arithmetic quite a few years ago, the break even point for CFLs was about 3 months. The bulbs I bought back then all lasted 6+ years. The cost of a CFL is around the cost of 3-10kWh, depending on the brand, so even if they incandescents were free you don't need the CFLs to last very long to break even.
Sounds like something's wrong with your wiring. I switched to using CFLs over a decade ago and the shortest lifetime I've had on one is 6 years (I think - one might have gone after 4). The first time I moved house, I brought a load with me, but they'd become so cheap that I didn't bother the last time. The only incandescents I've had last longer than a year are ones that are rarely used. I worked out that - back when they were expensive - that after 3 months of operation they'd saved me more in electricity than the cost of an equivalent incandescent, so they've been a pretty good investment.
I don't know why that's a surprise for you. Incandescents are also limited in terms of lifetime by being turned on and off. The thermal shock of taking a very thin wire filament from room temperature up to white hot in a fraction of a second is not very good for its lifetime. That's why lightbulbs are most likely to break when you turn them on.
Listening to users isn't necessarily a good thing. Henry Ford said that if he'd asked his customers what they wanted, they'd have asked for a faster horse. This is especially true of UI design, because most people (even power users) really don't measure what they're spending time doing and get into unproductive patterns. The problem with GNOME was that they also didn't listen to usability experts. Or even vaguely competent people who had read an HCI book. They went down a path of doing things that an uninformed user and a usability expert could both agree were stupid. Apparently they've improved recently, but it cost them a lot of users.
XP also tweaked the VM subsystem in a way that was quite noticeable if you had more than about 256MB of RAM (better performance), but the main feature it added was remote desktop (although only in the Pro version). I was quite tempted to upgrade from 2K for the remote desktop stuff.
I'm not a huge fan. The goal of D was to produce a better C++, but if you're designing a new language then C++ really isn't where I'd choose to start. It's not as bad as Ruby (I can't imagine the kind of person who would look at Smalltalk and say 'what this language really needs is Perl-like syntax'. Actually, I can't imagine the kind of person who'd say that about any language. Including Perl). Rust is probably the modern language that I like the most.
Not really. They've increased a bit above inflation, but the amount I'm spending on electricity has remained pretty constant, increasingly slightly below inflation (increases in device efficiency offsetting increase in costs). The amount I'm paying for gas has gone up a bit more.
I switched to DuckDuckGo and haven't looked back. They used to be noticeably worse in results quality, but Google has gone a long way downhill. Occasionally I don't find things with DDG and try Google. When I do, I have to wade through pages of totally irrelevant stuff to find that there are no matches, whereas at least DDG tells me straight away that it can only find half a dozen possibly-relevant things. I especially like the way DDG integrates with a number of domain-specific search engines.
How is the objective-c compiled and ran on Dalvik? Are you doing: objective-c -> LLVM -> dalvik bytecode?
It isn't. It runs natively via the NDK.
I maintain the GNUstep / Clang Objective-C stack. Most people who use it now do so in Android applications. A lot of popular apps have a core in Objective-C with the Foundation framework (sometimes they use GNUstep's on Android, more often they'll use one of the proprietary versions that includes code from libFoundation, GNUstep and Cocotron, but they almost all use clang and the GNUstep Objective-C runtime). Amusingly, there are actually more devices deployed with my Objective-C stack than Apple's. The advantage for developers is that their core logic is portable everywhere, but the GUIs can be in Objective-C with UIKit on iOS or Java on Android (or, commonly for games, GLES with a little tiny bit of platform-specific setup code). I suspect that one of the big reasons why the app situation on Windows Phone sucks is that you can't do this with a Windows port.
It would be great for these people to have an open source Swift that integrated cleanly with open source Objective-C stacks. Let's not forget that that's exactly what Swift is: a higher-level language designed for dealing with Objective-C libraries (not specifically Apple libraries).
Objective-C is a good language for mid-1990s development. Swift looks like a nice language for early 2000s development. Hopefully someone will come up with a good language for late 2010s development soon...
It wasn't just about interface. People tend to forget how search engines did an absolutely horrible job of intelligently ranking the sites you wanted to see.
I find it pretty easy to remember - I go to Google today.
The UI was what made me switch both to Google originally and from it some years later. When I started using Google - and when Google started gaining significant market share - most users were on 56Kb/s or slower modem connections. AltaVista was the market leader and they'd put so much crap in their front page that it took 30 seconds to load (and then another 20 or so to show the results). Google loaded in 2-3 seconds. The AltaVista search results had to be a lot better to be faster. I switched away when they made the up and down arrow keys in their search box behave differently to every other text field in the system.
My 'precious electronic toys' use about a tenth of the power that the ones I was using a decade ago for the same purpose did. Even lighting power consumption has dropped. My fridge, freezer and washing machine are the big electricity consumers in my home - efficiency has improved there, but nowhere near as fast as for gadgets.
There's a lot more to government than military intelligence gathering and law enforcement (although it would be a good idea for someone to remind most current governments that those are two things, not one). And most government projects end up spending insane budgets. This isn't limited to the US. It amazes me how often government projects to build databases to store a few million records with a few tens to thousands of queries per second (i.e. the kind of workload that you could run with off-the-shelf software on a relatively low-spec server) end up costing millions. Even with someone designing a pretty web-based GUI, people paid to manually enter all of the data from existing paper records, and 10 years of off-site redundancy, I often can't see where the money could have gone. Large companies often manage to do the same sort of thing.
The one thing that the US does well in terms of tech spending is mandate that the big company that wins the project should subcontract a certain percentage to small businesses. A lot of tech startups have got their big breaks from this rule.
Add to that, about 10-20% of the population get motion sick using the kind of VR in Oculus Rift (myself included - I can use it for 2-5 minutes, depending on the mode). It's ludicrous to imagine building a school that would exclude 20% of the potential pupils on some random criterion. You might as well make schools that didn't let in gingers...
Apple already ships 64-bit ARM chips and a lot of other vendors are racing to do so. The Android manufacturers that I've spoken want 64-bit for the same reason that they want 8-core: It's a marketing checkbox and they don't want to be shipping a 32-bit handset when their competitor is marketing 64-bit as a must-have feature. ART is in the top 10 worst-written pieces of code I've had to deal with and is full of casts from pointers to int32_t (not even a typedef, let alone intptr_t), but it should get a 64-bit port soon.
64-bit is here for a while. A lot of modern '64-bit' CPUs only support 40-bit physical addresses, so are limited to 'only' 128GB of RAM. Most support 48-bit virtual addresses (the top bit is sign extended, so all 1 or all 0 depending on whether you've got a kernel or userspace address), limiting you to 'only' 32TB of virtual addresses. If RAM sizes continue to double once every year, then it takes another year to use each bit. We currently have some machines with 256GB of RAM, so are using 41 bits. 64 bits will last another 23 years. RAM increases have slowed a bit recently though. 10 years ago, you always wanted as much RAM as possible because you were probably swapping whatever you were doing. Now, most computers are happy with 2GB for programs and the rest for buffer cache. As SSDs get faster, there's less need for caching, but there might be more need for address space as people want to be able to memory map all the files that they access...
The real problem for Firefox is not the interface changes that people like you whine about, it's mobile. Now 30% of traffic is mobile and Firefox doesn't have an app for any Apple mobile devices and is effectively excluded from Android by Google's Microsoft-like illegal anti-competitive licensing deals with manufacturers (you can get the app, but it's not preloaded and only a few geeks ever would).
Huh? It's in the Google Play Market and is no harder to install than any other app. Once it's installed, the first time you click on a link from another app you're asked to choose the app that will handle links. I fall into the geek category (and so installed it from F-Droid, not Google Play), but found it trivial to switch to Firefox on the mobile. I mostly did because Chrome has spectacularly bad cookie management and I'd been trying to find a browser that did it better. Early Firefox ports were as bad, but now it's quite nice and with the Self Destructing Cookies add-on does exactly what I want.
The mobile is actually the only place I use Firefox...
For some reason, people in the second category describe themselves as 'religious'. And yet you'll be hard-pressed to find, for example, a Christian who requires the same standards of evidence for the non-existence of the Norse, Egyptian, Greek or Hindu gods as he requires that an atheist from the first category provides for the non-existence of the Abrahamic god.
How about 'tablet'? Coming through Heathrow security, I get told to take laptops, iPads, and Kindles out of my bag. I guess any brand of laptop has to come out, but tablets and ebook readers only do if they're made by Apple or Amazon...