There's just no need for 99% of the features UEFI offers, like those silly UIs and built in apps that exist only because phoenix/AM are desperate to stay relevant and visible. Really all the firmware needs to do is get the hardware into a stable state, boot a kernel or chainload a system specific bootloader that handles preboot setup for that os, and then get the hell out of the way. Having the os call back into firmware code for hardware specific features sounds nice until you realize a lot of that bios code is completely broken on a lot of hardware. The old MBR standard has size limitations but it is far nicer to deal with than incomprehensible GUIDs. The latter is bad enough in windows.
Secure boot is only optional on x86 laptops/desktops. On other platforms it is used to block user-installed os. How long do you think it will be before that 'mandatory' option is simply not mandatory anymore?
Perhaps you never realized that the 'old' 'new stuff is cool' attitude came with an implied expectation/judgment of sensible/objective improvement, that, for the most part, products were passing (except for stuff like msbob). That hasn't changed. What has changed is the hierarchy of priorities within major software firms. Around 2000, the engineers were told to go to the back of the bus while the 'user experience designers' took over, targeting the soccer mom instead of the intelligent user. They prettyed everything up with lots of white space, oversized fonts, wordy and unmemorable phrases in place of single terms, and reduced the functionality and flexibility to something morons could comprehend. Oh, and then they slapped search boxes on everything to compensate for this braindead nonsense. Instead of knowing where things are in sensibly named and organized layouts, the user has to know the magic incantation search to bring up each. Welcome to the future.
The main complaints about windows 8+ comes from people using desktop/laptop computers to make the content used on touch devices. Touch/mobile interfaces don't work well for this at all. Who wants interfaces riddled with full screen 24pt font modal dialog boxes and tons of wasted whitespace? Who wants fingerprints on their monitors?
If today's software is used as an example, it seems like most team programmers are chosen for their willingness not to to rock the boat (or management ego) first and programming skills last.
It might be an old meme, but it's still true, especially for opengl. Their d3d is ok if you plan to run the games tweaked in that particular version of the driver.
It really depends on the game and your expectations for minimum framerate. If you want lots of gfx detail and high minimums, 1920x1080 still requires high end graphics.
Obviously, the efficiency of the C lib functions will vary by hardware and by author competence, but here's no way virtualized code could run faster and with less cpu and ram overhead than well written (or compiler generated) native code on given hardware.
An interesting bench done with 7 year old software and hardware (perhaps things are better today?). http://zi.fi/shootout/
While it's gotten a lot better since the 90s, ~35-50% slower is still significant (assuming you discount the 'compiled away' situations). The strings bench is near the bottom. Unfortunately, he did not measure memory footprint or calling overhead. This is too bad because this is another area where managed runtimes come up short.
For example, the installer for freespace2 SCP is java based, and it takes 50MB of ram on startup, and grows from there as it downloads files from the network. I use tinywall on my windows box, and currently that's sitting at over 100 MB..for something that just inserts rules into the system firewall based on PID/name. That's nuts for such simple programs.
Most managed programs call out to C libraries through shims when speed is needed because the vm carries too much overhead, even when the executable is targeted for specific hardware. For example, modern game engines do this a lot. The fact that virtualized logic can touch unmanaged space breaks the security model, making it pointless to expect any additional security from the virtualization.
stack smashing, buffer overflows, invalid pointer dereference, malloc failures, code overwriting done by a program written in pure Java?
Properly written C does not cause those. Buggy C certainly does, just like buggy vms. The fact that oracle has been patching java exploits for years suggests its security isn't much better than a typical unmanaged C++ program at least as far as the user's concerned.
I mentioned the UI/system integration before. For me this is reason enough to avoid managed/interpreted runtime programs unless I have no choice. The shimming and overhead is prone to breakage and there're usually native alternatives that behave better.
I only meant to imply that such law would basically require a license and key disclosure in order to setup a vpn. Your employer would have a license for this because they're a corp that can afford it.. your home vpn would require a separate license, complete with key disclosure of course.
A large percentage works just fine even with holes, and with greater performance and less overhead. The supposed claim to fame for java was that, while slower and resource intensive, it prevented programmers from writing exploitable code. Today, we know it's possible to make a shitpile with any tool, leaving java and other runtimes to sacrifice much of the potential for lean, high performance software for small gains in security (the latter with a growing list of caveats). I'm not a fan of such mediocrity but it has become the norm these days. It also doesn't help that java comes with a browser plugin that opens a complete runtime environment to drivebys. Microsoft abandoned activex for this reason.
Just because the majority think something is true or false doesn't make it so. Voting will not change reality. Washington's royalty culture needs to die.
Slashdot Mirror
No, you just lack reading comprehension skills.
Everyone knows the internet is for porn.. It is the internet of thingies..
There's just no need for 99% of the features UEFI offers, like those silly UIs and built in apps that exist only because phoenix/AM are desperate to stay relevant and visible. Really all the firmware needs to do is get the hardware into a stable state, boot a kernel or chainload a system specific bootloader that handles preboot setup for that os, and then get the hell out of the way. Having the os call back into firmware code for hardware specific features sounds nice until you realize a lot of that bios code is completely broken on a lot of hardware. The old MBR standard has size limitations but it is far nicer to deal with than incomprehensible GUIDs. The latter is bad enough in windows.
Secure boot is only optional on x86 laptops/desktops. On other platforms it is used to block user-installed os. How long do you think it will be before that 'mandatory' option is simply not mandatory anymore?
Perhaps you never realized that the 'old' 'new stuff is cool' attitude came with an implied expectation/judgment of sensible/objective improvement, that, for the most part, products were passing (except for stuff like msbob). That hasn't changed. What has changed is the hierarchy of priorities within major software firms. Around 2000, the engineers were told to go to the back of the bus while the 'user experience designers' took over, targeting the soccer mom instead of the intelligent user. They prettyed everything up with lots of white space, oversized fonts, wordy and unmemorable phrases in place of single terms, and reduced the functionality and flexibility to something morons could comprehend. Oh, and then they slapped search boxes on everything to compensate for this braindead nonsense. Instead of knowing where things are in sensibly named and organized layouts, the user has to know the magic incantation search to bring up each. Welcome to the future.
The main complaints about windows 8+ comes from people using desktop/laptop computers to make the content used on touch devices. Touch/mobile interfaces don't work well for this at all. Who wants interfaces riddled with full screen 24pt font modal dialog boxes and tons of wasted whitespace? Who wants fingerprints on their monitors?
eh, apparently you can't, mate.
If today's software is used as an example, it seems like most team programmers are chosen for their willingness not to to rock the boat (or management ego) first and programming skills last.
Simple, when the user clicks the url, the browser opens the appropriate application for the urltype. That's how it should be anyway.
because last time I checked, that requires logging into youtube/google.
Anyone dumb enough to depend on cloud services for critical workflow deserves what they get.
using [] brackets and [menu] you could break up the config.sys too, then in autoexec, reference the breaks with a GOTO %CONFIG%.
Judge the problem on its own merit and context rather than by the relative wealth of the person who has it.
or maybe systemd/linux!
Eventually systemd will replace GNU entirely, so it'd be linux/systemd.. eventually, the kernel will be forked too and it'll be redhat/systemd
It might be an old meme, but it's still true, especially for opengl. Their d3d is ok if you plan to run the games tweaked in that particular version of the driver.
It really depends on the game and your expectations for minimum framerate. If you want lots of gfx detail and high minimums, 1920x1080 still requires high end graphics.
Yes, if you're happy chugging along at 20-35fps with dips into the low teens.
'You get what you pay for' is also common sense.
Obviously, the efficiency of the C lib functions will vary by hardware and by author competence, but here's no way virtualized code could run faster and with less cpu and ram overhead than well written (or compiler generated) native code on given hardware.
An interesting bench done with 7 year old software and hardware (perhaps things are better today?).
http://zi.fi/shootout/
While it's gotten a lot better since the 90s, ~35-50% slower is still significant (assuming you discount the 'compiled away' situations). The strings bench is near the bottom. Unfortunately, he did not measure memory footprint or calling overhead. This is too bad because this is another area where managed runtimes come up short.
For example, the installer for freespace2 SCP is java based, and it takes 50MB of ram on startup, and grows from there as it downloads files from the network. I use tinywall on my windows box, and currently that's sitting at over 100 MB..for something that just inserts rules into the system firewall based on PID/name. That's nuts for such simple programs.
Most managed programs call out to C libraries through shims when speed is needed because the vm carries too much overhead, even when the executable is targeted for specific hardware. For example, modern game engines do this a lot. The fact that virtualized logic can touch unmanaged space breaks the security model, making it pointless to expect any additional security from the virtualization.
stack smashing, buffer overflows, invalid pointer dereference, malloc failures, code overwriting done by a program written in pure Java?
Properly written C does not cause those. Buggy C certainly does, just like buggy vms. The fact that oracle has been patching java exploits for years suggests its security isn't much better than a typical unmanaged C++ program at least as far as the user's concerned.
I mentioned the UI/system integration before. For me this is reason enough to avoid managed/interpreted runtime programs unless I have no choice. The shimming and overhead is prone to breakage and there're usually native alternatives that behave better.
I only meant to imply that such law would basically require a license and key disclosure in order to setup a vpn. Your employer would have a license for this because they're a corp that can afford it.. your home vpn would require a separate license, complete with key disclosure of course.
I never said this was a good idea. It's terrible.
A large percentage works just fine even with holes, and with greater performance and less overhead. The supposed claim to fame for java was that, while slower and resource intensive, it prevented programmers from writing exploitable code. Today, we know it's possible to make a shitpile with any tool, leaving java and other runtimes to sacrifice much of the potential for lean, high performance software for small gains in security (the latter with a growing list of caveats). I'm not a fan of such mediocrity but it has become the norm these days. It also doesn't help that java comes with a browser plugin that opens a complete runtime environment to drivebys. Microsoft abandoned activex for this reason.
Yup.. It's become quite the proto-singularity..
Just because the majority think something is true or false doesn't make it so. Voting will not change reality. Washington's royalty culture needs to die.
Why wouldn't it support html5 for netflix?
err I meant vfw not vfs.