Linked by Thom Holwerda on Tue 25th Sep 2012 22:40 UTC, submitted by Anonymous Coward
Windows NeoSmart Technologies has released a new version of EasyBCD, the free bootloader editor for Windows which supports Windows 8, the latest GRUB2 distributions, EFI machines, and comes with all-new support for 13 different languages. If you have a Windows-based multiboot machine, you really need EasyBCD. It's a fantastic application.
Thread beginning with comment 536638
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Good link
by Neolander on Thu 27th Sep 2012 08:45 UTC in reply to "RE[5]: Good link"
Neolander
Member since:
2010-03-08

The problem with all these approaches that try to add sandboxing functionality to existing OSs, is that sandboxing is only useful if users and developers are aware of its existence and ready to deal with it.

We have billions of Windows users out there who have been trained for decades to give root access to any "installer" program. How are Microsoft supposed to teach them that they should now be wary of such behaviour and expect a fine-grained description of what the program is up to ? Same thing for all these Mac users that know for sure that "If that Flash installer from abodeflashdownload.com wants to make changes to my computer and displays a window with a lock on it, I should sure give it my password !"

And then you have Fedora and iOS, which completely fail to understand what sandboxing is about and hide its existence away from users altogether...

Because of this legacy user problem, it seems to me that sandboxing can only be successfully implemented in new OSs or incompatible and rebranded forks of existing OSs. It is also just too bad that all too often, OS manufacturers also use it to force some locked-down "application store" down user's throat, making a bad name of an otherwise perfectly fine technology among expert users.

Reply Parent Score: 2

RE[7]: Good link
by darknexus on Thu 27th Sep 2012 09:02 in reply to "RE[6]: Good link"
darknexus Member since:
2008-07-15

The problem with all these approaches that try to add sandboxing functionality to existing OSs, is that sandboxing is only useful if users and developers are aware of its existence and ready to deal with it.

Even then, it won't be effective. No matter how tightly you sandbox something, you're eventually going to have to give it permission to access something. Whether it's a wordprocessor that you need to let access your documents folders (both local and remote) or a VOIP application that a user wants running on start-up, you will have to give it permission to access something outside of its own resources unless you want to end up like the Apple app stores. That approach works to an extent, but forces a massive inconvenience on more knowledgeable users. Not only do we not have access to the filesystem (which I could live with if I had to) but we can't send a file across to another application. Say I have an audio project which I'm recording. I then want to send portions of it over to an audio editor rather than a multi-track recorder program… oops, can't do that with iOS.
The long and short of it is that you will never have a perfect security mechanism. It doesn't matter how well you sandbox. When users are involved, you cannot prevent them from doing something stupid. It's rather like various systems of government in that respect: they look great on paper, but then you get people involved and somehow it never turns out as expected.
I think the best approach would be iOS-style sandboxing (notice I did not say having a locked down app store) but you need to allow either filesystem access or the ability to otherwise share data between applications. The instant you do that, you've essentially broken your sandbox. You have no choice however, if you want a fully-functional, productive environment. A balance between security and usability is, I think, the best we can ever hope for.

Reply Parent Score: 2

RE[8]: Good link
by moondevil on Thu 27th Sep 2012 09:18 in reply to "RE[7]: Good link"
moondevil Member since:
2005-07-08

Whether it's a wordprocessor that you need to let access your documents folders (both local and remote) or a VOIP application that a user wants running on start-up, you will have to give it permission to access something outside of its own resources unless you want to end up like the Apple app stores.


This is actually the way to go, to certain extent.

The wordprocessor does not need to be a single executable.

It can be composed by several executables, each with its own set of relevant permissions. Similar to what chrome or the new sandboxed quicktime player do.

The executable that reads/writes from the file system, is not the same executable responsible for editing the document.

All executables that compose a single logical application, communicate between each other via local RPC.

This makes it way harder to own the application.

But sure, it increases the complexity of development, and many developers are not smart enough to deal with this type of distributed architectures.

Reply Parent Score: 2