If the development is put into E to give it similar functionality to KDE or Gnome as an application platform then guess what? It will grow to consume resources in a similar manner.
If you think a desktop environment is all about eye candy you are mistaken. yes there is eye candy, but the more important thing they provide is a development platform for applications.
Newsflash: trading CPU cycles and RAM for more rapid development and use of shared libraries (rather than re-inventing the wheel constantly) is considered to be an acceptable trade-off.
Given that 16 GB of ram runs about $100 these days, running with 64 MEG is just making life more difficult for yourself than it has to be.
Anyway, the rc5 changes are pretty much all over: pretty much exactly
half are drivers (networking, usb, gpu, mmc, sound..), with the other
half being various other subsystems. Some arch updates: MIPS, arm,
smattering of ia64, microblaze, s390 and some x86. And networking
(non-driver), xfs, fuse, gfs2, jfs..
Well maybe, just maybe if he had a stable driver ABI (at least between releases in the same stable tree) he'd:
cut his work in half
actually have commercial driver support
Why every fucking driver under the sun belongs in the kernel tree (and thus, every driver change impacts the kernel) I have no idea.
True. Lets assume for the sake of argument that we are talking about Google adopting the code-signing policy, and giving out free code-signing certs with the device with a 10 year expiry date. Is this acceptable?
It is my firm belief that we need some sort of third party verification because end users are simply easily fooled, and even if the app store is fooled, at least if code is signed they can turn the cert off after the software is in the wild.
The issues people have with Apple's code signing requirement are not insurmountable, if apple or another company was to attempt it. I just don't think the current Google approach of allowing any unsigned code to be verified by the end user is a solution. This is what we've had with Windows for the past 2-3 decades...
And that's fine. Good for you. It doesn't change the fact that allowing end users to install unsigned code from anywhere has been demonstrated to NOT WORK for the past 30 years. As I said, the certificate issue / xcode issue is not a technical problem, and iOS is merely an example of where I think we need to go with security.
We already rely on SSL certs to decide whether or not to trust a website with our password, yet most people will freely download and install (and grant privileges - whatever they have to do to make the shiny work) unverified code from untrusted sources that can then do anything it likes with their system.
Yes, and so do you. If you were to see a guy in a hood brandishing a pistol and running away from the police, would you talk to him? You pre-screen people you deal with whether you will admit it or not.
You have replaced a code signing certificate (of say, 2048 bits of entropy) with a PIN. Other than that, you have described code-signing. And again, relying on the user to run SUDO or not puts the security in the hands of the user. Who is often a muppet and has no idea what they are doing with regards to security or doesn't care. Until they get owned. Making them jump through hoops to install things is still going to result in them installing things they shouldn't.
OS X, Airport, iPhone, AppleTV all play together nicely
I have the budget to choose either. After being a DOS/Windows/Linux guy for 20 years (in that order), I find OS X has the easiest things to deal with that piss me off about it, and plenty of things that are "oh, that's cool" that I discover from time to time the more I use it.
In fact, I think that's the big difference between OS X and Windows - In windows I am constantly trying to do things or diagnose things and run into brick walls (and coming up disappointed). On OS X or Linux I am more often than not discovering something cool in the process.
As per my other post, an end user, prompted for authorisation to install something they downloaded (even if it is malicious) is going to click "yes" or enter their password. Without a development background, the source code, possibly a debugger and a few days up their sleeve, the choice to install or not is entirely uninformed.
It is blind luck as to whether or not the app they have downloaded is trojaned or not, unless it has been vetted upstream in some manner.
2 decades of Windows being pwned and Google learns... nothing
So, so much this.
Relying on the end user to magically be aware that stuff they are signing is not trojaned, reputable, etc. is not going to work. As demonstrated by Microsoft for the last 30 years, and as demonstrated in the unix world since the 70s.
I've been saying for some time that Android is the Windows of the mobile world. Not because of the code-base or even quality of the code-base, but due to the design decision to push security back on the end user. 99.999% of us are not security experts.
Virus scanners are a waste of resources (cpu/storage and thus, battery).
Vet executables at the source. If the user wants to run their own code, provide a code signing mechanism (this can be done on iOS with a dev account, sure there is a cost argument but the technical benefit is huge. if it was free and there was sufficient verification of an individual's identity to prevent issuing multiple certs to the same person, the money issue could go away. at the moment the cost is there to make obtaining thousands (say) of code-signing certs impractical for a malware author). If apple included a code-signing cert for the end user to "bless" their own (or downloaded) code with for use on their own devices, would people's bitching about not "owning" their iOS device change?
This is the single biggest reason I am an iOS user. I've been around long enough to know not to trust myself or any of my users to vet apps themselves (no one has the time or skillset or tools to do it anyway). I have no faith in the security of a device which can run any code from anywhere being in the hands of an end user (including myself) who is not capable of verifying whether or not code is malicious.
No it is not a 100% solution and there is every chance that malware slips through, however once it has been reported to the distribution point, its cert can be revoked to stop it spreading any further.
Yes, exploits can be created if the signing mechanism is secure, but that is an implementation issue, not a core design issue, and can be fixed.
Docking stations won't be around much longer other than niche uses. WIDI, Gigabit WIFI, etc. Cables suck - give me an inductive charging pad, wireless everything else.
And yeah, a retina MBP 13 will most certainly get a Quad core haswell is my bet. What could get real interesting is if intel figure out a crossfire/sli type setup with a pair of Haswell CPU/GPUs. Can you say 16 thread/dual quad core high end notebook with better than Nvidia GT650M graphics capability in ~90w of power?
I have no doubt that WON'T be coming out, but in future, the CPU/GPU combo has such a huge power consumption advantage over current discrete options it opens up some interesting possibilities.
MBP 15 will stay discrete is my bet - for at least a couple more generations until intel catch up a bit more (its a big differentiator between pro and air at the moment). However an MBA with Haswell iris and 16GB of ram and 512GB of storage would be a very attractive prospect. Nvidia / AMD should be concerned...
And when you run out of fuel, or are forced to abandon your solar panel installation? Charging via solar whilst running for your life not so practical:D
To be fair, apple are fairly open/specific with the conditions of their test, available on their website. If you are running the GPU/CPU a lot harder then you will chew battery a lot more. As per my other post.
Is that your typical workload? In reality, most people use laptops on battery to do work on word documents, email or powerpoint.
Obligatory car analogy: Are you suggesting we test fuel economy on vehicles whilst driving uphill in 40C with the A/C on, towing a caravan of the maximum rated towing capacity?
No... the tests are better aimed at a typical workload, or a typical workload being performed in a reasonably battery conservative manner.
If you are not a typical user, then obviously they need to be taken with a pinch of salt.
Estimating worse case isn't too hard anyway - work out watt/h of the battery and max TDP of the CPU/GPU (the two biggest power hogs) and it is a simple case of say (for example) 40 watt cpu + 45 watt GPU = 85 watts. Battery = 65 watt/hr = you will get 65/85 * 60 minutes of battery life, approximately.
My MBP gets say, 8 hours (real world) when I am running 30-40 percent screen brightness, keyboard backlight off, not playing audio or video and just reading/typing lightweight stuff on-lin.e
If I crank up a game or 3d modelling program, handbrake, etc... well.... running neverwinter nights, the battery life drops to 45 minutes (I tested it for a laugh).
25 hrs of light usage would be good in transit where you are doing say, an international trip to somewhere remote, or are using your laptop to charge other devices (say, a smartphone you are using for internet service) when out and about. Or, '25 hours" would also be useful to get at least a couple of hours or more of heavy duty work done while not at a desk, or during a power outage..
Pressure will be on Nvidia (or AMD) for the next one to improve GPU power consumption no doubt.
Yes, GPU switching helps, but there's still a bunch of dumb stuff which enables the high end GPU under OS X, and you'll see battery life literally HALVE as soon as that happens - even if the machine is mostly idle. At least thats my experience with my 2011 MBP 15".
Sure, more intelligent GPU switching improvements will help, but haswell will make the higher end GPUs a lot "more expensive" (relative to total machine power draw) to drive and make said GPU switching even more important.
Slashdot Mirror
If the development is put into E to give it similar functionality to KDE or Gnome as an application platform then guess what? It will grow to consume resources in a similar manner.
If you think a desktop environment is all about eye candy you are mistaken. yes there is eye candy, but the more important thing they provide is a development platform for applications.
Newsflash: trading CPU cycles and RAM for more rapid development and use of shared libraries (rather than re-inventing the wheel constantly) is considered to be an acceptable trade-off.
Given that 16 GB of ram runs about $100 these days, running with 64 MEG is just making life more difficult for yourself than it has to be.
Well maybe, just maybe if he had a stable driver ABI (at least between releases in the same stable tree) he'd:
Why every fucking driver under the sun belongs in the kernel tree (and thus, every driver change impacts the kernel) I have no idea.
Except that on apple's website they are quite specific about the test conditions...
True. Lets assume for the sake of argument that we are talking about Google adopting the code-signing policy, and giving out free code-signing certs with the device with a 10 year expiry date. Is this acceptable?
It is my firm belief that we need some sort of third party verification because end users are simply easily fooled, and even if the app store is fooled, at least if code is signed they can turn the cert off after the software is in the wild.
The issues people have with Apple's code signing requirement are not insurmountable, if apple or another company was to attempt it. I just don't think the current Google approach of allowing any unsigned code to be verified by the end user is a solution. This is what we've had with Windows for the past 2-3 decades...
And that's fine. Good for you. It doesn't change the fact that allowing end users to install unsigned code from anywhere has been demonstrated to NOT WORK for the past 30 years. As I said, the certificate issue / xcode issue is not a technical problem, and iOS is merely an example of where I think we need to go with security.
We already rely on SSL certs to decide whether or not to trust a website with our password, yet most people will freely download and install (and grant privileges - whatever they have to do to make the shiny work) unverified code from untrusted sources that can then do anything it likes with their system.
It's insane.
Yes, and so do you. If you were to see a guy in a hood brandishing a pistol and running away from the police, would you talk to him? You pre-screen people you deal with whether you will admit it or not.
You have replaced a code signing certificate (of say, 2048 bits of entropy) with a PIN. Other than that, you have described code-signing. And again, relying on the user to run SUDO or not puts the security in the hands of the user. Who is often a muppet and has no idea what they are doing with regards to security or doesn't care. Until they get owned. Making them jump through hoops to install things is still going to result in them installing things they shouldn't.
What keeps me ON windows (at work):
What keeps me OFF windows (mostly) at home:
I have the budget to choose either. After being a DOS/Windows/Linux guy for 20 years (in that order), I find OS X has the easiest things to deal with that piss me off about it, and plenty of things that are "oh, that's cool" that I discover from time to time the more I use it.
In fact, I think that's the big difference between OS X and Windows - In windows I am constantly trying to do things or diagnose things and run into brick walls (and coming up disappointed). On OS X or Linux I am more often than not discovering something cool in the process.
As per my other post, an end user, prompted for authorisation to install something they downloaded (even if it is malicious) is going to click "yes" or enter their password. Without a development background, the source code, possibly a debugger and a few days up their sleeve, the choice to install or not is entirely uninformed.
It is blind luck as to whether or not the app they have downloaded is trojaned or not, unless it has been vetted upstream in some manner.
So, so much this.
Relying on the end user to magically be aware that stuff they are signing is not trojaned, reputable, etc. is not going to work. As demonstrated by Microsoft for the last 30 years, and as demonstrated in the unix world since the 70s.
I've been saying for some time that Android is the Windows of the mobile world. Not because of the code-base or even quality of the code-base, but due to the design decision to push security back on the end user. 99.999% of us are not security experts.
Virus scanners are a waste of resources (cpu/storage and thus, battery).
Vet executables at the source. If the user wants to run their own code, provide a code signing mechanism (this can be done on iOS with a dev account, sure there is a cost argument but the technical benefit is huge. if it was free and there was sufficient verification of an individual's identity to prevent issuing multiple certs to the same person, the money issue could go away. at the moment the cost is there to make obtaining thousands (say) of code-signing certs impractical for a malware author). If apple included a code-signing cert for the end user to "bless" their own (or downloaded) code with for use on their own devices, would people's bitching about not "owning" their iOS device change?
This is the single biggest reason I am an iOS user. I've been around long enough to know not to trust myself or any of my users to vet apps themselves (no one has the time or skillset or tools to do it anyway). I have no faith in the security of a device which can run any code from anywhere being in the hands of an end user (including myself) who is not capable of verifying whether or not code is malicious.
No it is not a 100% solution and there is every chance that malware slips through, however once it has been reported to the distribution point, its cert can be revoked to stop it spreading any further.
Yes, exploits can be created if the signing mechanism is secure, but that is an implementation issue, not a core design issue, and can be fixed.
... where's the iOS version? Oh wait...
Docking stations won't be around much longer other than niche uses. WIDI, Gigabit WIFI, etc. Cables suck - give me an inductive charging pad, wireless everything else.
And yeah, a retina MBP 13 will most certainly get a Quad core haswell is my bet. What could get real interesting is if intel figure out a crossfire/sli type setup with a pair of Haswell CPU/GPUs. Can you say 16 thread/dual quad core high end notebook with better than Nvidia GT650M graphics capability in ~90w of power?
I have no doubt that WON'T be coming out, but in future, the CPU/GPU combo has such a huge power consumption advantage over current discrete options it opens up some interesting possibilities.
MBP 15 will stay discrete is my bet - for at least a couple more generations until intel catch up a bit more (its a big differentiator between pro and air at the moment). However an MBA with Haswell iris and 16GB of ram and 512GB of storage would be a very attractive prospect. Nvidia / AMD should be concerned...
And when you run out of fuel, or are forced to abandon your solar panel installation? Charging via solar whilst running for your life not so practical :D
This is why i don't trust important stuff to somebody else's cloud.
Would you like a pony with that?
To be fair, apple are fairly open/specific with the conditions of their test, available on their website. If you are running the GPU/CPU a lot harder then you will chew battery a lot more. As per my other post.
Is that your typical workload? In reality, most people use laptops on battery to do work on word documents, email or powerpoint.
Obligatory car analogy: Are you suggesting we test fuel economy on vehicles whilst driving uphill in 40C with the A/C on, towing a caravan of the maximum rated towing capacity?
No... the tests are better aimed at a typical workload, or a typical workload being performed in a reasonably battery conservative manner.
If you are not a typical user, then obviously they need to be taken with a pinch of salt.
Estimating worse case isn't too hard anyway - work out watt/h of the battery and max TDP of the CPU/GPU (the two biggest power hogs) and it is a simple case of say (for example) 40 watt cpu + 45 watt GPU = 85 watts. Battery = 65 watt/hr = you will get 65/85 * 60 minutes of battery life, approximately.
It all depends on your useage.
My MBP gets say, 8 hours (real world) when I am running 30-40 percent screen brightness, keyboard backlight off, not playing audio or video and just reading/typing lightweight stuff on-lin.e
If I crank up a game or 3d modelling program, handbrake, etc... well .... running neverwinter nights, the battery life drops to 45 minutes (I tested it for a laugh).
25 hrs of light usage would be good in transit where you are doing say, an international trip to somewhere remote, or are using your laptop to charge other devices (say, a smartphone you are using for internet service) when out and about. Or, '25 hours" would also be useful to get at least a couple of hours or more of heavy duty work done while not at a desk, or during a power outage..
But yes, niche cases...
You laugh, but when the zombie apocalypse hits, he'll have a working flashlight for more than a few hours :D
Pressure will be on Nvidia (or AMD) for the next one to improve GPU power consumption no doubt.
Yes, GPU switching helps, but there's still a bunch of dumb stuff which enables the high end GPU under OS X, and you'll see battery life literally HALVE as soon as that happens - even if the machine is mostly idle. At least thats my experience with my 2011 MBP 15".
Sure, more intelligent GPU switching improvements will help, but haswell will make the higher end GPUs a lot "more expensive" (relative to total machine power draw) to drive and make said GPU switching even more important.
Apple also sells a lot more iphones outside of the USA now.
err... plus DosBox is running x86 software I have from 198x...which is 30+ years now.