That's a security problem with Intel hardware don't you think ?
Security through obscurity doesn't work. It's possible to make a safe hardware, so that reverse engineering (as rightfully understood by the EU laws) is applied and legal for compatibility. And even (gasp) open-specced hw.
Even by hardware, I do not mean realy that : software doesn't mean driver OR app OR os, you have firmware too.
What prevents me from making a DIVX in hyper good resolution/quality ? (aside from tweaking the codecs so that the parameters will be optimized for such resolutions ?)
Of course the crappy screener on 320*240 won't be that fantastic on imax, but what about 10000x10000 pixels with a good compression ratio ? (or better)
That's something that i've been wondering, why not use comrpession to remove unvisible information while using the added bandwith / capacity for increased quality ? (example: 1hour of 96khz 48 bits audio on a CD would be great to hear - better than an uncompressed CD i'd think)
Besides, is it WM9 or MPEG4 ? I thought the chosen MPEG4 standard container was qt)
I think the difference is the Kernel : cygwin uses the win32 kernel to run cygwin programs as win32 applications (which they are), as colinux runs a linux kernel as a win32 application, whic in turn runs applications.
use last mandrake (some other distro have, I'm sure, about the same level of polish):
You can change the display resolution quickly in Windows. : ctrl-alt-+/- on X, and next version with the xrandr extension (i think), will have a control panel for it in main desktops.
I can install items in Windows with a few point and clicks. : on mandrake, you signle clic on one item, dependencies are automatically resolved and the thing is installed. You just have to enter the root password. For your modem, I don't know, but generally, yes h/w support is stilla pb on linux.
And that's true, snowboarding is hard on the beginning. don't give up, after the first day it'll be a bliss. Like Linux. Except linux has not been ported to a snowboard. yet.
I've been following loads of discussions among ISPs, for example, who see nothing fundamentally wrong with limiting traffic to ports 25, 110 and 143
Wow, no port 80 for us ? yay. And, of course, limiting traffic to port 110 is really more secure. Like, I couldn't use some remote Http-RPC interface to telnet, (or use a POP3 email very dumb vb virus). Or a port-80-downloaded spyware.
I think this suggestion, while slghtly convenient for loading (but is it the kernel that takes long to load ? If not wouldn't the whole OS be very long to load ? And there are other means to say 'read only', such as.. boot off CD-R).
But what security point will it solve ? Either you have a 'secure' OS and it might guarantee that untrusted sources are kept off the priviledge data, or you'll have a software somewhat 'insecure' (like, 100% of software is today). And then, it'll not be possible to patch the software (purposedly), do not install any 3rd party 'root' software (or else any soft might have root access).
So, IF you have only a kernel in ROM and no documents, yes your box is more secure. Else, if you can h4x0r a root program, replace it with a fake, steal content without changing the kernel, using a well-known hole (no security updates for you), would you find this box to be very secure ?
Wow, I cannot have put something wronger in less terms. Do not feed the trolls, but... I will.
Perl6 does not do anything (doesn't exist yet), and will execute... perl6 code. (although its VM, parrot, will supposedly be -and already is- able to execute other language (as the Java VM is, just write a compiler for any strange language to java bytecode, although it han't been made fot that, of course.)
Java is a mess : I will pass on these plainly false, non proved assertions.
I agree that Perl is a really compiled language. Compilation to bytecode is a real compilation. If you mean compilation to native code, well, you're just plain wrong.
you don't have to chosse J2ME or C++ to program an app in a series 60. Java bindings are available and can be full series 60 software. (see http://www.symbian.com/technology/standard-java.ht ml)
I think porting perl here will not add a lot to what's available.
Paul, I would like to use this thread to ask your opinion on a subject : would you think jack is suitable for processing video ?
I know, they are two completely different subjects, but as I think Ardour does video, how hard/useful would you think extending LADSPA / Jack to video could be ?
despised with a reaon : while extremely promising, I never got to get arts working properly -and consuming 20% CPU - nor have I found a correct (up to date) programming documentation for it.
However, it's not cross-toolkit, so difficult to consider as a goal.
OK, I'm a bit overstating, and installing gtk+ on a system is not generally very such a big pb.
However, when exactly have you installed glib without the full gtk+ ? Sorry, but glib, gobject, gdk and gtk ARE a common package (and developed as is : same developers, same version numbers, same CVS) in most if not all distros.
Ergo, a dependency on glib is, for now and practically speaking, a dependency on GTK+. Thus, on a widget toolkit.
GTK+ is not built on glib and gobject : they belong to GTK+.
I reckon GStreamer is what Arts for KDE should have been , but !
I think that if this GStreamer relies on gtk+ (even on gobject or glib), its chances to become the standard directX is nil.
Too bad, but having gtk+ as a dependency to install kde-multimedia... is somewhat funny.
Could this prog be separated between UI dependant and toolkitn agnistic (yes, gtk+ is a freakin' X widget toolkit.. anbd I hope it will saty so)
Not saying Qt's better or GTK+ is (god forbid), but an audio underlying should NOIT have dependency on a widget toolkit if it has to be the standard.
Look at LADSPA (linux standard for audio plugins. Yes, both of them. just kidding), its dependency are very, very bare. And, that's a good thing. GStreamer doesn't even need to be based on gnome.
What's next, Postgresql replication having a dependency on a MySQL library ?
Besides, I think that the quality of the gstreamer is realy exciting, but I don't see it becoming the standard media infrastructure for KDE.
OK for your input, I approve totally the lack of esd, arts,... However, Jack is useful if you need syncing several sources : jack is not a mixer (but can host one), it's a high end synchronisation framework. The ouput of jack is often alsa, but could be ardour for example. How can you do that with dmix ?
How exactly is a language designed to scale well ? In LoC ? Sorry but, while J2EE might be designed to scale well, Java is a language, and beyond that, was not designed for scalability, but portability. Remember it was an embedded language on the beginning.
Building a system around Microsoft CMS is one heck of a lot better than mucking arround trying to make CVS do this type of thing. I don't have an issue with that part. But $2 million to customize it...
Well, duh, Building a CM system around Zope+Plone is one hack of a lot better and easier than mucking around trying to make Access do that type of thing.
Slashdot Mirror
just hope they stored it on unsigned ints ...
That's a security problem with Intel hardware don't you think ?
Security through obscurity doesn't work. It's possible to make a safe hardware, so that reverse engineering (as rightfully understood by the EU laws) is applied and legal for compatibility. And even (gasp) open-specced hw.
Even by hardware, I do not mean realy that : software doesn't mean driver OR app OR os, you have firmware too.
You KNOW you some can have this at home ? Oh, maybe more ./ people have arcade cabinets than SO ...
(typos fixed) : that quote would be more interesting if you RTF end of the sentence.
while using the added bandwith / capacity for increased quality
What do you mean when you say "Psycho-visual" and "psycho-acoustic" modelling removes stuff that you can't ?
My idea was to use compression to improve perceived quality, bandwith being a constant.
What prevents me from making a DIVX in hyper good resolution/quality ? (aside from tweaking the codecs so that the parameters will be optimized for such resolutions ?)
Of course the crappy screener on 320*240 won't be that fantastic on imax, but what about 10000x10000 pixels with a good compression ratio ? (or better)
That's something that i've been wondering, why not use comrpession to remove unvisible information while using the added bandwith / capacity for increased quality ? (example: 1hour of 96khz 48 bits audio on a CD would be great to hear - better than an uncompressed CD i'd think)
Besides, is it WM9 or MPEG4 ? I thought the chosen MPEG4 standard container was qt)
and ./ and it's peculiar gramar was a famous sujbect of stduy for her.
Because, for any people having an nforce2 board, they will be able to use their ethernet controller on a stable kernel.
I think the difference is the Kernel : cygwin uses the win32 kernel to run cygwin programs as win32 applications (which they are), as colinux runs a linux kernel as a win32 application, whic in turn runs applications.
When you move up ?
*tada*
use last mandrake (some other distro have, I'm sure, about the same level of polish) :
You can change the display resolution quickly in Windows. : ctrl-alt-+/- on X, and next version with the xrandr extension (i think), will have a control panel for it in main desktops.
I can install items in Windows with a few point and clicks. : on mandrake, you signle clic on one item, dependencies are automatically resolved and the thing is installed. You just have to enter the root password.
For your modem, I don't know, but generally, yes h/w support is stilla pb on linux.
And that's true, snowboarding is hard on the beginning. don't give up, after the first day it'll be a bliss. Like Linux. Except linux has not been ported to a snowboard. yet.
Wow, no port 80 for us ? yay. And, of course, limiting traffic to port 110 is really more secure. Like, I couldn't use some remote Http-RPC interface to telnet, (or use a POP3 email very dumb vb virus). Or a port-80-downloaded spyware.
I think this suggestion, while slghtly convenient for loading (but is it the kernel that takes long to load ? If not wouldn't the whole OS be very long to load ? And there are other means to say 'read only', such as .. boot off CD-R).
But what security point will it solve ? Either you have a 'secure' OS and it might guarantee that untrusted sources are kept off the priviledge data, or you'll have a software somewhat 'insecure' (like, 100% of software is today). And then, it'll not be possible to patch the software (purposedly), do not install any 3rd party 'root' software (or else any soft might have root access).
So, IF you have only a kernel in ROM and no documents, yes your box is more secure. Else, if you can h4x0r a root program, replace it with a fake, steal content without changing the kernel, using a well-known hole (no security updates for you), would you find this box to be very secure ?
Wow, I cannot have put something wronger in less terms. Do not feed the trolls, but ... I will.
... perl6 code. (although its VM, parrot, will supposedly be -and already is- able to execute other language (as the Java VM is, just write a compiler for any strange language to java bytecode, although it han't been made fot that, of course.)
Perl6 does not do anything (doesn't exist yet), and will execute
Java is a mess : I will pass on these plainly false, non proved assertions.
I agree that Perl is a really compiled language. Compilation to bytecode is a real compilation. If you mean compilation to native code, well, you're just plain wrong.
you don't have to chosse J2ME or C++ to program an app in a series 60. Java bindings are available and can be full series 60 software. (see http://www.symbian.com/technology/standard-java.ht ml)
I think porting perl here will not add a lot to what's available.
Paul, I would like to use this thread to ask your opinion on a subject : would you think jack is suitable for processing video ?
I know, they are two completely different subjects, but as I think Ardour does video, how hard/useful would you think extending LADSPA / Jack to video could be ?
Libxml2 can and is installed without gnome.
Glib isn't. Glib is part of GTK+.
Would you say the same with pango ?
despised with a reaon : while extremely promising, I never got to get arts working properly -and consuming 20% CPU - nor have I found a correct (up to date) programming documentation for it.
However, it's not cross-toolkit, so difficult to consider as a goal.
OK, I'm a bit overstating, and installing gtk+ on a system is not generally very such a big pb.
However, when exactly have you installed glib without the full gtk+ ? Sorry, but glib, gobject, gdk and gtk ARE a common package (and developed as is : same developers, same version numbers, same CVS) in most if not all distros.
Ergo, a dependency on glib is, for now and practically speaking, a dependency on GTK+. Thus, on a widget toolkit.
GTK+ is not built on glib and gobject : they belong to GTK+.
I reckon GStreamer is what Arts for KDE should have been , but !
... is somewhat funny.
.. anbd I hope it will saty so)
I think that if this GStreamer relies on gtk+ (even on gobject or glib), its chances to become the standard directX is nil.
Too bad, but having gtk+ as a dependency to install kde-multimedia
Could this prog be separated between UI dependant and toolkitn agnistic (yes, gtk+ is a freakin' X widget toolkit
Not saying Qt's better or GTK+ is (god forbid), but an audio underlying should NOIT have dependency on a widget toolkit if it has to be the standard.
Look at LADSPA (linux standard for audio plugins. Yes, both of them. just kidding), its dependency are very, very bare. And, that's a good thing. GStreamer doesn't even need to be based on gnome.
What's next, Postgresql replication having a dependency on a MySQL library ?
Besides, I think that the quality of the gstreamer is realy exciting, but I don't see it becoming the standard media infrastructure for KDE.
It's ... a duck !
OK for your input, I approve totally the lack of esd, arts, ...
However, Jack is useful if you need syncing several sources : jack is not a mixer (but can host one), it's a high end synchronisation framework.
The ouput of jack is often alsa, but could be ardour for example. How can you do that with dmix ?
> Java is designed to scale well on big programs
How exactly is a language designed to scale well ? In LoC ?
Sorry but, while J2EE might be designed to scale well, Java is a language, and beyond that, was not designed for scalability, but portability. Remember it was an embedded language on the beginning.
Well, it's nice for me to define an error margin with a ratio.
1dB = (10^0.1)*100 % error margin, (if i'm not mistaken) : exactly same meaning, sounds alright.
a "-1, redundant" generator.
Well, duh, Building a CM system around Zope+Plone is one hack of a lot better and easier than mucking around trying to make Access do that type of thing.