Now it'll just require some time to trickle down to production-quality distros.
Re:Vala makes the creating widgets argument moot
on
Qt Becomes LGPL
·
· Score: 1
However, Vala itself is deliberately C#-like. And that's going to cause problems.
C++ has a lot of nice memory handling features: automatic objects, various smart pointers, etc. Also, C++ makes memory management very explicit while Vala tries to hide it.
And it's even WORSE if Vala is used for widgets. Because a memory leak in a nice Vala widget can bring down a large well-written application which uses this widget.
(it's also possible to write portable widgets using GTKmm, but I digress)
Re:Vala makes the creating widgets argument moot
on
Qt Becomes LGPL
·
· Score: 1
Yeah, sure.
Vala is a massive pile of failure on the scale of VB6. It doesn't contain a garbage collector _or_ a cycle detector. So it's VERY easy to leak memory by creating cycles of objects.
It's OK for small applets that don't allocate much objects anyway. However in large applications it'll soon become a BIG problem.
EVERY time you boot Windows. And this option will also be gone soon.
"Do you take issue with the 'tainted' bit in kernel modules too? Or with the many compile-time options in the kernel? Giving users the power to decide whether unsigned code is able to run in kernel mode sounds like a smart idea to me."
Does Linux require me to press F8 _EACH_ time I boot it and then select 'enable tainted modules'?
Once more: driver signing requirement DOES NOT MAKE DRIVERS BETTER. Period.
There's no requirement for drivers to pass any tests. You just pay for your certificate and then you can sign anything. Microsoft reserves right to revoke your certificate if you develop a driver to bypass DRM, of course.
For example, I help to develop Dokan driver (http://dokan-dev.net/en/) - it has a signed version. One signed version (not available for download now) had at least one exploitable buffer overflow bug. However, you can install it without any questions (in fact, I'm working on support for transparent installation).
Personally, I like signed drivers and kernels. I have a TPM in my Thinkpad notebook which I'm going to use to ensure only signed (by me) Linux kernel can be loaded. But not when it's done with the sole purpose to add more shackles for benefit of MAFIAA.
Signed drivers are as likely to crash as unsigned ones. There's no mandatory testing requirements for signed drivers.
Microsoft actually did a fair job of improving driver quality by releasing WHQL test suits. However, this has absolutely nothing to do with driver signing.
Rootkits can use several unreliable methods to inject themselves into kernel space.
For example, they can use bugs in existing drivers for good old buffer overflows. They can use 'magically press f8 during boot' trick. They can use hypervisors before Windows kernel is loaded.
Or they can get a certificate from Microsoft.
In any case, most of malware works purely in userspace and is not affected by the driver signing requirement.
"You contradict yourself. First you say it cannot be turned off, then you say it cannot be turned off without losing premium content playback."
It can't be turned off without enabling 'test mode'. Turning on test mode shows ugly 'test mode' markers at the corners of the desktop, so it's not feasible for end-users.
I've mentioned DRM playback to prove the fact that driver signing is tied to DRM. There's no other reason for it.
Nope. That's a part of DRM (and the essential part). Any DRM scheme is useless if you have access to kernel mode. Thus, securing kernel mode is a prerequisite for any moderately secure DRM.
"Yes, you can turn off the driver signing requirement, just like you can in Vista."
Nope.
YOU CAN'T TURN OFF DRIVER SIGNING REQUIREMENT IN VISTA x64.
There's ABSOLUTELY NO WAY to do it without losing premium content playback capability.
In short, there's NO WAY to disable driver checks now without resorting to test mode.
General public SHOULD be able to install unsigned drivers. It's not your right to tell them what NOT to do. Anyway, inability to install drivers is certainly a limitation compared to WXP.
If you disagree, then please explain how freedom is slavery and ignorance is strength.
I can turn on 'test mode', but it uglyfies the desktop. It's OK for development (I develop Windows drivers!), but absolutely NOT OK for general public.
The main problem with encryption now is that you can't remember good enough keys anymore.
It's quite possible to brute-force ten-letter alphanumeric passwords. With some assumptions it should be possible to brute-force even larger passwords.
"So what you're saying then, if I got this right, is that the best audio system on the planet is the one that you have to write yourself? Awesome."
Yep. That's about right - I want a no-nonsense small and fast system on top of which additional layers can be built.
"Didn't say it was hard. Said no other OS is doing it. Your argument seems to be that it's possible to do something, therefore it's already been done."
ALL OTHER OSes DO THIS ALREADY!!!
In XP you either needed driver support (like in Creative drivers) or a special DirectShow filter.
Vista only adds a nice GUI for these settings. In fact, I'll probably add a GUI editor for delay lines to PulseAudio when I'll have some spare time.
"Show me another OS that, out of the box, has the same feature set that Vista has. Any linux distro. Any kernel. And I'll concede that Vista doesn't have the most advanced audio system. Until them blather on, but you're still wrong."
Well, show me at least one OS apart from Linux with PulseAudio which allows me to broadcast hi-def 24-bit music over the LAN with autodetection based on ZeroConf and I'll concede that Linux doesn't have the most advanced audio system. Until them blather on, but you're still wrong.
Slashdot Mirror
Have you heard about COM? You know, a cross-language toolkit which is widely used in Windows?
Look inside it - it can be built right on top of C++ objects. And it has FAR less overhead than gobjects in GTK.
So C++ bindings can certainly be done.
It's pronounced as a sound closer to 'a' than to 'o'. Also, Americans usually stress the wrong syllable (it's "soYUz").
http://www.reuters.com/article/pressRelease/idUS144846+15-Apr-2008+PRN20080415
"QNX Achieves Boot Times in Milliseconds on the Intel(R) Atom(TM) Processor Z500 Series"
It's possible. And it has already been done with Linux: http://lwn.net/Articles/299483/
Now it'll just require some time to trickle down to production-quality distros.
However, Vala itself is deliberately C#-like. And that's going to cause problems.
C++ has a lot of nice memory handling features: automatic objects, various smart pointers, etc. Also, C++ makes memory management very explicit while Vala tries to hide it.
And it's even WORSE if Vala is used for widgets. Because a memory leak in a nice Vala widget can bring down a large well-written application which uses this widget.
(it's also possible to write portable widgets using GTKmm, but I digress)
Yeah, sure.
Vala is a massive pile of failure on the scale of VB6. It doesn't contain a garbage collector _or_ a cycle detector. So it's VERY easy to leak memory by creating cycles of objects.
It's OK for small applets that don't allocate much objects anyway. However in large applications it'll soon become a BIG problem.
I wouldn't have any problems with driver signing in Windows if it allowed me:
1) To use my own certificate to re-sign drivers (i.e. allow to install my own trusted root certificate).
2) Turn off signing validation.
"You can select either option at boot-time"
EVERY time you boot Windows. And this option will also be gone soon.
"Do you take issue with the 'tainted' bit in kernel modules too? Or with the many compile-time options in the kernel? Giving users the power to decide whether unsigned code is able to run in kernel mode sounds like a smart idea to me."
Does Linux require me to press F8 _EACH_ time I boot it and then select 'enable tainted modules'?
Once more: driver signing requirement DOES NOT MAKE DRIVERS BETTER. Period.
There's no requirement for drivers to pass any tests. You just pay for your certificate and then you can sign anything. Microsoft reserves right to revoke your certificate if you develop a driver to bypass DRM, of course.
For example, I help to develop Dokan driver (http://dokan-dev.net/en/) - it has a signed version. One signed version (not available for download now) had at least one exploitable buffer overflow bug. However, you can install it without any questions (in fact, I'm working on support for transparent installation).
Personally, I like signed drivers and kernels. I have a TPM in my Thinkpad notebook which I'm going to use to ensure only signed (by me) Linux kernel can be loaded. But not when it's done with the sole purpose to add more shackles for benefit of MAFIAA.
Signed drivers are as likely to crash as unsigned ones. There's no mandatory testing requirements for signed drivers.
Microsoft actually did a fair job of improving driver quality by releasing WHQL test suits. However, this has absolutely nothing to do with driver signing.
AFAIR, KBs can not be uninstalled if SP1 is present. In any case, that's not an acceptable solution.
Kernel security might have been nice, if it was configurable.
Right now, it's just a tool of DRM-loving bastards at Microsoft.
Rootkits can use several unreliable methods to inject themselves into kernel space.
For example, they can use bugs in existing drivers for good old buffer overflows. They can use 'magically press f8 during boot' trick. They can use hypervisors before Windows kernel is loaded.
Or they can get a certificate from Microsoft.
In any case, most of malware works purely in userspace and is not affected by the driver signing requirement.
"You contradict yourself. First you say it cannot be turned off, then you say it cannot be turned off without losing premium content playback."
It can't be turned off without enabling 'test mode'. Turning on test mode shows ugly 'test mode' markers at the corners of the desktop, so it's not feasible for end-users.
I've mentioned DRM playback to prove the fact that driver signing is tied to DRM. There's no other reason for it.
Nope. That's a part of DRM (and the essential part). Any DRM scheme is useless if you have access to kernel mode. Thus, securing kernel mode is a prerequisite for any moderately secure DRM.
"Yes, you can turn off the driver signing requirement, just like you can in Vista."
Nope.
YOU CAN'T TURN OFF DRIVER SIGNING REQUIREMENT IN VISTA x64.
There's ABSOLUTELY NO WAY to do it without losing premium content playback capability.
http://www.osronline.com/showthread.cfm?link=97522
In short, there's NO WAY to disable driver checks now without resorting to test mode.
General public SHOULD be able to install unsigned drivers. It's not your right to tell them what NOT to do. Anyway, inability to install drivers is certainly a limitation compared to WXP.
If you disagree, then please explain how freedom is slavery and ignorance is strength.
"You can in Vista too! Only 64 bits stops that"\
Yep. It's called 'slowly boiling a frog'.
"and you can disable that behavior if you want!"
How?
I can turn on 'test mode', but it uglyfies the desktop. It's OK for development (I develop Windows drivers!), but absolutely NOT OK for general public.
Can I install unsigned drivers on Windows 7?
Whoops!
Israel doesn't try to exclude non-Jews. Sure. It even has 20 Arabs in Knesset.
That's because Jews know the value of good PR. Israel's politics is effectively quite nationalistic and Arabs do not have much influence on it.
In defense of SVN: it works VERY WELL with large files. We keep hundreds of gigabytes of drawings/photos/designs in SVN without any problem.
Hg/git _suck_ at handling large binary files.
Words "network collision" are going to take a whole new meaning :)
Nope, it's not. It's actually a horrible passphrase, since it contains only dictionary words.
Nope. Effective password alphabet is about 70 characters (26*2+10+punctuation).
You can also assume that passwords are unlikely to have 4 or more consecutive punctuation marks, contain parts of dictionary words, etc.
The main problem with encryption now is that you can't remember good enough keys anymore.
It's quite possible to brute-force ten-letter alphanumeric passwords. With some assumptions it should be possible to brute-force even larger passwords.
"So what you're saying then, if I got this right, is that the best audio system on the planet is the one that you have to write yourself? Awesome."
Yep. That's about right - I want a no-nonsense small and fast system on top of which additional layers can be built.
"Didn't say it was hard. Said no other OS is doing it. Your argument seems to be that it's possible to do something, therefore it's already been done."
ALL OTHER OSes DO THIS ALREADY!!!
In XP you either needed driver support (like in Creative drivers) or a special DirectShow filter.
On Linux you can use ALSA "delay line" plugin: http://www.linuxjournal.com/node/7391/print . Or you can use one of these plugins: http://plugin.org.uk/ladspa-swh/docs/ladspa-swh.html
Vista only adds a nice GUI for these settings. In fact, I'll probably add a GUI editor for delay lines to PulseAudio when I'll have some spare time.
"Show me another OS that, out of the box, has the same feature set that Vista has. Any linux distro. Any kernel. And I'll concede that Vista doesn't have the most advanced audio system. Until them blather on, but you're still wrong."
Well, show me at least one OS apart from Linux with PulseAudio which allows me to broadcast hi-def 24-bit music over the LAN with autodetection based on ZeroConf and I'll concede that Linux doesn't have the most advanced audio system. Until them blather on, but you're still wrong.
It would be true if there was a way to override driver signing requirement.
It could be fairly done rootkit-proof, for example only during boot time or by using a special signed utility from Microsoft.