1. Cisco routers suck at IPv6. Many of cisco's routers use the router's CPU to process IPv6 packets instead of the fast-path. The reasons for this are explained in the next few points. While Juniper's routers are substantially better at IPv6 than cisco's, IT managers are often restrained by insane corporate policy that dictactes the use of cisco.
Oh, you're right, Cisco doesn't support IPv6 well, lets just drop the whole thing. What a great point you have here.
2. There are too many addresses. There are 16.7 million addresses per square metre of the earth's surface, including the oceans. This is overkill. The world does not need more than the 4 billion addresses available with IPv4, and I challenge you to come up with an application that requires that many. Assuming that you can actually come up with one, it could easily be solved with Network Address Translation, or NAT as it is commonly known.
Oh, ofcourse having too-many addresses in itself is a huge problem (we might have to leave some addresses unallocated - the horror!). Yet another great point.
3. IPv6 addresses are too large. An IPv6 address is 128 bits in size - 64 bits of which are reserved for addressing hosts, and 64 bits of which are reserved for routing. One thing that is cool with IPv6 is address autoconfiguration. Take your 56-bit MAC address on your ethernet card, ask for 64-bits of network prefix, bang it together with EUI-64 and you are set. The problem with a 64-bit network prefix is that routing tables become massive. Just do the math and you'll see that extreme amounts of memory are required to hold routing tables.
If you're trying to say 128-bit is too large because routing tables become too large, that's simply ignorant. IPv4 addresses are so small that they cannot easily be geographically/connection-wise allocated. This means that routing tables became large because of the complexity of IPv4 addressing. 128-bit allow much simpler addressing schemes which will actually make routing tables much simpler, and probably smaller, even though each address is a few bytes longer.
4. The IPv6 header is too large. An IPv4 header compact at 20 bytes in length, while the IPv6 is bloated at 40 bytes. That's right people, each one of your IP packets has twice as much overhead as before. While this may not sound much, IP networks have a requirement that the minimum MTU supported must be 576 bytes. That means that where you might have got 556 bytes of data in your IP packets, you now get 536 bytes. This means that downloading stuff will take 3.4% longer.
A) The fact that the minimum MTU required is 576 bytes is meaningless, real MTU's are much higher. B) Few networks actually use all of the potential ether/link bandwidth all of the time, so a few percents of extra/lower usage don't matter much. C) The overhead of IP packets is almost negligible anyway, and this does not change it considerably.
When comparing the popularity of the two, do not forget that vi is fairly standard and that vim is fairly small.
This means that whoever uses emacs should have no problem also installing vi/vim, while those who use vi/vim wouldn't typically install emacs/xemacs, which are much larger.
The only reason the unprecedented blatantly-unjustified restrictions on every human on the planet currently survive in public opinion, is that everyone infringes on these copyrights and they are not enforced.
One of two things is likely to happen: A) The status-quo continues for a long while, where most infringe on copyrights, and a few fund the companies that keep these restrictions running - until Free Software and increased infringement squeezes out almost all Copyrighted software out of existence.
B) "Trusted computing" (more accurately described "Treacherous computing") actually enforces Copyrights on most humans in the planet. The public, suddenly suffering the true consequences of copyright, will quickly change its opinion on copyrights and they will not survive for long, if politicians want to stay in office.
Those programmers that distribute the malicious software on P2P networks are just examples of the moral decay society has been experiencing in regard to Freedom of information, backed by the media companies and their successful name-calling campaigns ("copyright infringers are pirates, thieves", etc). Fortunately, people do value this freedom and will vote for it if they can no longer infringe on it - so our freedom is most probably safe.
An example of this happening is with Python's lambda, which messed up the lexical scope issue and so makes people think lambda isn't particularly useful.
Python lambdas are just syntatic-sugar around nested functions (defined just as normal functions). In fact, Guido regrets putting them in the language, as he thinks you should use a nested-def instead.
I think you are quite out-of-touch with current Python, because since Python 2.1, Python has had useful nested functions with lexical scoping. There is a slight ugliness issue about assigning into new variables in the containing scope, but they are slight. I use nested functions in my Python code _all the time_, they're one of the most useful features in Python.
It seems to me that you are attracted more to FP languages because of their coherency. That indeed is a huge plus, however I think you might be missing out on the reason of the "ad-hoc" feel most "imperative"* languages have.
Languages like Python, C and others (excluding C++), usually have a bit of historic baggage (That adds up in _every_ practical language), but mostly they feel ad-hoc, because they are attempting to solve an ad-hoc problem: Providing a useful platform to develop arbitrary programs that work on arbitrary machines.
A set of arbitrary demands usually results in an "ad-hoc" solution, though that is not really an obstacle to actual development in real-world projects (Excluding perhaps formal proofs).
I feel very comfortable writing Functional-style python (combinations of map/filters/lambdas, now more coherently put with list/generator comprehensions), and yet I still prefer to write some of my code in more imperative style.
Object-orientation in traditional languages is an unholy mess, for example, an example of the kind of ad-hoc crap I was talking about. You'll get more insight into what OO is attempting to achieve if you examine Haskell's typeclasses (or you can play with them in Scheme, via this post).
Nobody actually agrees these days on what OO actually means. The most common definition states support for: A) Encapsulation B) Inheritance C) Polymorphism
Basically this is attempting to achieve better modularity and reusability of code, and in some cases (Smalltalk, Python, Ruby) it is very successful, so I don't exactly see what you mean.
The real-world test [amounts of useful working code created out there] also seems to indicate that Python (without commercial giants backing it) is beating the hell out of Lisp, Haskell, and soon Java as well. If FP languages are so much more powerful and save so much work, why are they failing this test? When answering this, please keep in mind that Python was just recently in the same position of Haskell, or even worse, in terms of popularity and available code libraries.
Footnotes: * Scheme is more like Python than it is like Haskell, so I really cannot see why you'd name Python imperative while naming Scheme a FP.
You're assuming that because I saw a piece of Haskell as Mind-boggling - that I do not know advanced computing principles or am not serious about programming.
I am very serious about programming, and have accumulated a bit of knowledge and expertise along the way.
I do know and kinda like Scheme, and have tried approaching Haskell, ML and OCaml. These languages, however, always seemed to take more effort/LOC's and have far less practical code-bases available to them than Python, for example. They also have far steeper learning curves.
Python fits the way most human minds work, including those of experienced programmers, like myself or the more-experienced Eric Raymond.
Pure FP languages are more about purity than practical advantages and purity just doesn't justify the disadvantages, when you are not going to prove your program correct anyways.
As a sidenote, calling C "crap that evolved before people knew what computing was about" is at best inaccurate, as C was designed around the way computers operated as a portable assembly - with obvious knowledge of what computers are about.
That you prefer this code to the C alternative, in terms of readability, maintainability, error-proneness, etc?
Sure, I don't like using C for general-purpose programming as much as the next HLL programmer, but FP languages are simply mind-boggling, and no - that's not a good thing.
"Trusted Computing" will not make computing any more secure, not with its intended backwards compatability and strictly non-capability based design.
Not to mention Microsoft already indirectly controls most of its dumb consumers simply because it controls the software that runs their machines.
"Trusted Computing" will only let Microsoft and other large corporations control the few users who still do control their computers, and combined with the vastly successful Document Format lock-in, we will all be stuck with computers that Microsoft controls, or without the ability to communicate with mostly anyone.
"Trusted Computing" (more accurately described "Treacherous computing") is horrible, and all the myths about it solving any security problems are just a propoganda attempt to get users to "upgrade" their computers into total Microsoft control.
Yes, the whole idea IS that it would be very similar to the way ports are handled these days, except without the extra complexity.
Getting rid of ports will not allow much new functionality (except simpler DNS addressing of entities at any level, perhaps), but simplify existing protocols.
I was under the impression that UDP checksums are only for the headers, though I now see it does optionally checksum the data.
In any case, such a checksum should be implemented at the application level because it is optional.
The only thing UDP adds upon IP is the src/dest ports.
Other than that, UDP packets are plain IP packets, with all the ordering/bit-error-rate issues concerned. (In actuality, UDP has a header checksum, but the header only contains the ports).
IPv4 and IPv6 have a slight ugliness people have come to take for granted. This could be fixed for IPv7.
The concept of "ports". Ports are actually in-host entity identifiers, while the IP address itself is an in-network entity identifier. There should really be only one type of entity identifier, especially when it is 128-bit long.
The idea is that the last few bits of an IP address would typically serve the function of a "port". This way, a DNS server could translate names to much more specific entities than full hosts. It would allow hosting multiple FTP servers on the same host, for example, without the clients having to connect to different ports. It would dissolve the need for the silly ad-hoc workarounds with virtual web hosts.
This kind of addressing also allows much simplification of applications that would no longer need to use multiplexing over their connections. Instead, each application could allocate addressable "entities" and the multiplexing can be handled by the network layer.
Finally, it would eliminate the need for the UDP protocol entirely, as in-host identifying becomes part of the network layer itself.
TCP-layer becomes simpler as there is no need to handle in-host addressing as well.
Lets eliminate ports, for a simpler network protocol:-)
Huh? The Qt designer is the best designer out there, and the Qt toolkit is the fastest toolkit out there to code with.
With the Qt Designer 3 (and/or KDevelop), you have all the RAD integration you have in other tools, except Qt also does all of the layout management well, without having to worry about internationalization, etc.
Whatever it is you use, it is probably far worse off than Qt, in the RAD perspective and otherwise:-)
Because there's a really easy call in the Win32 API that "opens" a file, or does whatever Explorer defines as opening that file. Mail programs are encouraged to piggyback off this Explorer functionality. Said call was not developed when network security was an issue, and "integrating" office suites and the OS was a primary goal of MS. Apple was doing the same thing with OpenDoc.
API's that make some insecure things easy are not "bad". API's should be easy, whether or not they make insecure things easy. This is akin to blaming the tool rather than its user.
As for languages, Python is great, and its "slowness" is a non-issue for the vast majority of software code that needs to get written (probably more than 99% of the LOC's written these days). Whereever Python is "too slow", you can put a piece of Pyrex instead, or just use Psyco.
You should actually read the line, and not try to read between the line and itself. You might notice that I did not even imply that Windows doesn't get work done but merely that people don't necessarily care about specific Windows apps. People want general capabilities from their apps - capabilities they can find in KDE as well as Windows.
With KDE, though, people can copy the code to their neighbour, change the code, learn from the code - without being called pirates or being jailed.
That's why there's a KDE wrapper to mplayer, as well as kaboodle, noatun and maybe others - all of which are KDE and follow KDE guidelines.
Re:Trollish comment in the article
on
KDE 3.2.0 Released
·
· Score: 5, Insightful
Bingo. Unless it actually runs on Windows, or it has some emulation in it that actually runs _all_ Windows programs without hassles, I can't see the point in switching from Windows to KDE.
Maybe your purpose in using a computer is running Windows apps, most people want to get their work done.
Let's face it, the only value of an OS or computer is running the software _I_ want to run. And the desktop is little more than a very superficial interface to the OS.
The value of an OS is letting you do what you want to do. That may or may not involve running specific software.
The whole thing is like saying "now, see, we can give you a dashboard for your car that looks exactly like an airplane dashboard." Uh. And the point is? It's still a car, and it still can't do what an airplane does. Nor viceversa.
Huh? KDE is not trying to be Windows, its trying to be a useful desktop. One factor in being a good desktop is being able to look like Windows, so that many people will find it less difficult to switch - but its not its purpose.
The same applies to Linux vs Windows. Repeat after me: putting a Windows desktop manager on Linux, doesn't make it a Windows substitute. And viceversa, putting CDE (or a clone thereof) on Windows, doesn't make it a Unix workstation.
KDE is not a Windows(TM) desktop manager.
A good desktop is a substitute for Windows.
But even if we're discussing desktop makeups: does Linux now have CUA guidelines? Did people start actually sticking to the same behaviour for their widgets? Did people actually start testing their interfaces with 100 dpi fonts? Etc.
In the Free Software/Open Source world - such tests come for free. People use the software with all sorts of configurations and report problems. Not to mention Qt (And other modern toolkits), unlike Windows, uses pure logical layouts and handles font sizes/etc very well.
Because changing the desktop means very little, when Joe Average's day still involves dealing with 10 different programs, using 6 fundamentally different widget sets, 8 fundamentally different keyboard shortcut sets, and 4 different ways of even persisting his preferences.
That's exactly the purpose of KDE. Creating a consistent GUI to do all those things. KDE is slowly getting rid of the GUI concept of "application", integrating capabilities to run software in contexts of all apps and windows (KPart/IOSlave technologies). KDE also has a very consistent default keyboard shortcut setup. KDE is not about Gtk+ integration and consistency, but about internal integration and consistency (even though some projects to similarize do exist).
A lot of Windows's or a Mac's appeal doesn't come just from the way the desktop looks, nor from their particular flavour of widgets. It comes from the fact that everything running on it has the same standardized interface.
KDE is now more uniform and consistent than Windows and the vast amounts of inconsistent 3rd party apps. As for Macs, I haven't tried - but its probably hard to force UI guidelines/etc on 3rd party companies as you can force them with Free Software (simply modify any inconsistent application to follow the guidelines).
The way a Windows scroll bar or file open dialog works isn't perfect. (I actually prefer the Motif scroll bars.) But you can learn to use it _once_ and then apply that knowledge instinctively in all programs, from now until kingdom come.
Oh, I haven't seen my KDE scrollbar changing across applications.
Basically what I'm saying is: KDE is good and fine, and optimizing it doesn't hurt, but... IMHO what would really do Linux a world of good is enforcing a consistent interface across _all_ widget sets. Drag the good Qt, KDE, Gnome, Motif/Lesstif, GTK, etc people into a room, and don't let them out until they can aggree on a common interface standard;) That'll do Linux a world of good.
You can always use themes and such to make Gtk+/KDE look and behave similar. However, you're really supposed to be able to get along with just one of the toolkits - not having to worry about such inter-toolkit consistency.
Everyone seems to be inaccurate about what exactly Stallman's visit came to advocate. Human lives are saved and lost on literal accuracy - please attempt to be accurate.
Most people have replied with answers of the Open Source idealogy.
Open Source is a coherent and constistent philosophy of software development. Open Source holds to the goal of creating good software, with code sharing being the best mean towards that goal.
Since this article is about Richard Stallman, it is probably also appropriate to respond with the answer of the Free Software idealogy. Free Software is also a coherent and consistent philosophy - not of software development, but of freedom of information in general. Unlike Open Source, Free Software holds to the goal of individual/society Freedom, with good software resulting merely as a byproduct. In other words, Free Software means that even in case properiatly-licensed software offers a significant practical benefit to the alternate piece of Free Software, one should use the Free Software alternative - in order to not sign himself to secrecy against all of his peers.
Under the philosophy of Free Software, its simply and utterly unacceptable for someone to sign an NDA, or to restrict the changing or sharing of software. Forcing people to keep secrets from others is considered a crime against everyone in society.
It is therefore easy to envision how the GPL was created. The GPL is not about less restrictions, but about attempting to minimize the ability of others to restrict information sharing or impose secrecy.
It uses the API's of the host OS. It can mount its own Filesystems on block devices that are actually files on the host OS.
By writing a virtual file system driver that simply uses the host OS FS api's, you can "natively" access the Windows file system in the coLinux binaries. This means that Linux will access the NTFS data via Windows, and it can have its own ext2 block-device-over-file as well.
This is quite powerful and much nicer than cygwin which requires a lot of work per application ported.
Well, ofcourse since Linux runs in ring0 it can trash Windows.
If Windows trashes the system then you're screwed whether or not you run CoLinux on it.
The idea is that CoLinux does not do any I/O or have any drivers (which removes the dangerous part) nor does it touch physical memory in a way that's likely to interfere with Windows.
All physical memory is allocated from Windows via Windows' API's and only in a very extreme bug could the Linux virtual page tables be messed up so that they end up pointing at Windows pages and those pages get messed up in a bad way by yet another bug.
Most CoLinux crashes yield a double-fault which is handled by special code that can safely shut down the CoLinux virtual box which is totally harmless to the hosting Windows.
To actually crash Windows in CoLinux is very unlikely.
Slashdot Mirror
1. Cisco routers suck at IPv6. Many of cisco's routers use the router's CPU to process IPv6 packets instead of the fast-path. The reasons for this are explained in the next few points. While Juniper's routers are substantially better at IPv6 than cisco's, IT managers are often restrained by insane corporate policy that dictactes the use of cisco.
Oh, you're right, Cisco doesn't support IPv6 well, lets just drop the whole thing. What a great point you have here.
2. There are too many addresses. There are 16.7 million addresses per square metre of the earth's surface, including the oceans. This is overkill. The world does not need more than the 4 billion addresses available with IPv4, and I challenge you to come up with an application that requires that many. Assuming that you can actually come up with one, it could easily be solved with Network Address Translation, or NAT as it is commonly known.
Oh, ofcourse having too-many addresses in itself is a huge problem (we might have to leave some addresses unallocated - the horror!). Yet another great point.
3. IPv6 addresses are too large. An IPv6 address is 128 bits in size - 64 bits of which are reserved for addressing hosts, and 64 bits of which are reserved for routing. One thing that is cool with IPv6 is address autoconfiguration. Take your 56-bit MAC address on your ethernet card, ask for 64-bits of network prefix, bang it together with EUI-64 and you are set. The problem with a 64-bit network prefix is that routing tables become massive. Just do the math and you'll see that extreme amounts of memory are required to hold routing tables.
If you're trying to say 128-bit is too large because routing tables become too large, that's simply ignorant. IPv4 addresses are so small that they cannot easily be geographically/connection-wise allocated. This means that routing tables became large because of the complexity of IPv4 addressing.
128-bit allow much simpler addressing schemes which will actually make routing tables much simpler, and probably smaller, even though each address is a few bytes longer.
4. The IPv6 header is too large. An IPv4 header compact at 20 bytes in length, while the IPv6 is bloated at 40 bytes. That's right people, each one of your IP packets has twice as much overhead as before. While this may not sound much, IP networks have a requirement that the minimum MTU supported must be 576 bytes. That means that where you might have got 556 bytes of data in your IP packets, you now get 536 bytes. This means that downloading stuff will take 3.4% longer.
A) The fact that the minimum MTU required is 576 bytes is meaningless, real MTU's are much higher.
B) Few networks actually use all of the potential ether/link bandwidth all of the time, so a few percents of extra/lower usage don't matter much.
C) The overhead of IP packets is almost negligible anyway, and this does not change it considerably.
You are obviously a troll.
When comparing the popularity of the two, do not forget that vi is fairly standard and that vim is fairly small.
This means that whoever uses emacs should have no problem also installing vi/vim, while those who use vi/vim wouldn't typically install emacs/xemacs, which are much larger.
Please refrain from name-calling.
Copyright infringement is not "theft" or "piracy", it is a non-serious crime, while theft is a felony and piracy is just name-calling.
If you think Copyright infringement is a sin, please try avoiding saying it as though it was fact.
One way or another.
The only reason the unprecedented blatantly-unjustified restrictions on every human on the planet currently survive in public opinion, is that everyone infringes on these copyrights and they are not enforced.
One of two things is likely to happen:
A) The status-quo continues for a long while, where most infringe on copyrights, and a few fund the companies that keep these restrictions running - until Free Software and increased infringement squeezes out almost all Copyrighted software out of existence.
B) "Trusted computing" (more accurately described "Treacherous computing") actually enforces Copyrights on most humans in the planet. The public, suddenly suffering the true consequences of copyright, will quickly change its opinion on copyrights and they will not survive for long, if politicians want to stay in office.
Those programmers that distribute the malicious software on P2P networks are just examples of the moral decay society has been experiencing in regard to Freedom of information, backed by the media companies and their successful name-calling campaigns ("copyright infringers are pirates, thieves", etc).
Fortunately, people do value this freedom and will vote for it if they can no longer infringe on it - so our freedom is most probably safe.
Please don't describe copyright infringement as theft or piracy.
It is petty name-calling attempting to shove your moral view upon others.
Copyright infringement is a non-serious crime [look "infringement" up in the dictionary].
Distributing malicious software is a felony, a serious crime.
An example of this happening is with Python's lambda, which messed up the lexical scope issue and so makes people think lambda isn't particularly useful.
Python lambdas are just syntatic-sugar around nested functions (defined just as normal functions). In fact, Guido regrets putting them in the language, as he thinks you should use a nested-def instead.
I think you are quite out-of-touch with current Python, because since Python 2.1, Python has had useful nested functions with lexical scoping. There is a slight ugliness issue about assigning into new variables in the containing scope, but they are slight. I use nested functions in my Python code _all the time_, they're one of the most useful features in Python.
It seems to me that you are attracted more to FP languages because of their coherency. That indeed is a huge plus, however I think you might be missing out on the reason of the "ad-hoc" feel most "imperative"* languages have.
Languages like Python, C and others (excluding C++), usually have a bit of historic baggage (That adds up in _every_ practical language), but mostly they feel ad-hoc, because they are attempting to solve an ad-hoc problem: Providing a useful platform to develop arbitrary programs that work on arbitrary machines.
A set of arbitrary demands usually results in an "ad-hoc" solution, though that is not really an obstacle to actual development in real-world projects (Excluding perhaps formal proofs).
I feel very comfortable writing Functional-style python (combinations of map/filters/lambdas, now more coherently put with list/generator comprehensions), and yet I still prefer to write some of my code in more imperative style.
Object-orientation in traditional languages is an unholy mess, for example, an example of the kind of ad-hoc crap I was talking about. You'll get more insight into what OO is attempting to achieve if you examine Haskell's typeclasses (or you can play with them in Scheme, via this post).
Nobody actually agrees these days on what OO actually means. The most common definition states support for:
A) Encapsulation
B) Inheritance
C) Polymorphism
Basically this is attempting to achieve better modularity and reusability of code, and in some cases (Smalltalk, Python, Ruby) it is very successful, so I don't exactly see what you mean.
The real-world test [amounts of useful working code created out there] also seems to indicate that Python (without commercial giants backing it) is beating the hell out of Lisp, Haskell, and soon Java as well. If FP languages are so much more powerful and save so much work, why are they failing this test?
When answering this, please keep in mind that Python was just recently in the same position of Haskell, or even worse, in terms of popularity and available code libraries.
Footnotes:
* Scheme is more like Python than it is like Haskell, so I really cannot see why you'd name Python imperative while naming Scheme a FP.
You're assuming that because I saw a piece of Haskell as Mind-boggling - that I do not know advanced computing principles or am not serious about programming.
I am very serious about programming, and have accumulated a bit of knowledge and expertise along the way.
I do know and kinda like Scheme, and have tried approaching Haskell, ML and OCaml. These languages, however, always seemed to take more effort/LOC's and have far less practical code-bases available to them than Python, for example. They also have far steeper learning curves.
Python fits the way most human minds work, including those of experienced programmers, like myself or the more-experienced Eric Raymond.
Pure FP languages are more about purity than practical advantages and purity just doesn't justify the disadvantages, when you are not going to prove your program correct anyways.
As a sidenote, calling C "crap that evolved before people knew what computing was about" is at best inaccurate, as C was designed around the way computers operated as a portable assembly - with obvious knowledge of what computers are about.
Slashdot lameness filter is annoying :P
That you prefer this code to the C alternative, in terms of readability, maintainability, error-proneness, etc?
Sure, I don't like using C for general-purpose programming as much as the next HLL programmer, but FP languages are simply mind-boggling, and no - that's not a good thing.
HUH? What's that got to do with anything?
"Trusted Computing" will not make computing any more secure, not with its intended backwards compatability and strictly non-capability based design.
Not to mention Microsoft already indirectly controls most of its dumb consumers simply because it controls the software that runs their machines.
"Trusted Computing" will only let Microsoft and other large corporations control the few users who still do control their computers, and combined with the vastly successful Document Format lock-in, we will all be stuck with computers that Microsoft controls, or without the ability to communicate with mostly anyone.
"Trusted Computing" (more accurately described "Treacherous computing") is horrible, and all the myths about it solving any security problems are just a propoganda attempt to get users to "upgrade" their computers into total Microsoft control.
Yes, the whole idea IS that it would be very similar to the way ports are handled these days, except without the extra complexity.
Getting rid of ports will not allow much new functionality (except simpler DNS addressing of entities at any level, perhaps), but simplify existing protocols.
I was under the impression that UDP checksums are only for the headers, though I now see it does optionally checksum the data.
In any case, such a checksum should be implemented at the application level because it is optional.
The only thing UDP adds upon IP is the src/dest ports.
Other than that, UDP packets are plain IP packets, with all the ordering/bit-error-rate issues concerned. (In actuality, UDP has a header checksum, but the header only contains the ports).
IPv4 and IPv6 have a slight ugliness people have come to take for granted. This could be fixed for IPv7.
:-)
The concept of "ports". Ports are actually in-host entity identifiers, while the IP address itself is an in-network entity identifier.
There should really be only one type of entity identifier, especially when it is 128-bit long.
The idea is that the last few bits of an IP address would typically serve the function of a "port". This way, a DNS server could translate names to much more specific entities than full hosts. It would allow hosting multiple FTP servers on the same host, for example, without the clients having to connect to different ports. It would dissolve the need for the silly ad-hoc workarounds with virtual web hosts.
This kind of addressing also allows much simplification of applications that would no longer need to use multiplexing over their connections. Instead, each application could allocate addressable "entities" and the multiplexing can be handled by the network layer.
Finally, it would eliminate the need for the UDP protocol entirely, as in-host identifying becomes part of the network layer itself.
TCP-layer becomes simpler as there is no need to handle in-host addressing as well.
Lets eliminate ports, for a simpler network protocol
or Qt didn't blow as a RAD tool
:-)
Huh? The Qt designer is the best designer out there, and the Qt toolkit is the fastest toolkit out there to code with.
With the Qt Designer 3 (and/or KDevelop), you have all the RAD integration you have in other tools, except Qt also does all of the layout management well, without having to worry about internationalization, etc.
Whatever it is you use, it is probably far worse off than Qt, in the RAD perspective and otherwise
Because there's a really easy call in the Win32 API that "opens" a file, or does whatever Explorer defines as opening that file. Mail programs are encouraged to piggyback off this Explorer functionality. Said call was not developed when network security was an issue, and "integrating" office suites and the OS was a primary goal of MS. Apple was doing the same thing with OpenDoc.
API's that make some insecure things easy are not "bad". API's should be easy, whether or not they make insecure things easy. This is akin to blaming the tool rather than its user.
As for languages, Python is great, and its "slowness" is a non-issue for the vast majority of software code that needs to get written (probably more than 99% of the LOC's written these days). Whereever Python is "too slow", you can put a piece of Pyrex instead, or just use Psyco.
You should actually read the line, and not try to read between the line and itself. You might notice that I did not even imply that Windows doesn't get work done but merely that people don't necessarily care about specific Windows apps. People want general capabilities from their apps - capabilities they can find in KDE as well as Windows.
With KDE, though, people can copy the code to their neighbour, change the code, learn from the code - without being called pirates or being jailed.
That's why there's a KDE wrapper to mplayer, as well as kaboodle, noatun and maybe others - all of which are KDE and follow KDE guidelines.
Maybe your purpose in using a computer is running Windows apps, most people want to get their work done.
Let's face it, the only value of an OS or computer is running the software _I_ want to run. And the desktop is little more than a very superficial interface to the OS.
The value of an OS is letting you do what you want to do. That may or may not involve running specific software.
The whole thing is like saying "now, see, we can give you a dashboard for your car that looks exactly like an airplane dashboard." Uh. And the point is? It's still a car, and it still can't do what an airplane does. Nor viceversa.
Huh? KDE is not trying to be Windows, its trying to be a useful desktop. One factor in being a good desktop is being able to look like Windows, so that many people will find it less difficult to switch - but its not its purpose.
The same applies to Linux vs Windows. Repeat after me: putting a Windows desktop manager on Linux, doesn't make it a Windows substitute. And viceversa, putting CDE (or a clone thereof) on Windows, doesn't make it a Unix workstation.
KDE is not a Windows(TM) desktop manager.
A good desktop is a substitute for Windows.
;) That'll do Linux a world of good.
But even if we're discussing desktop makeups: does Linux now have CUA guidelines? Did people start actually sticking to the same behaviour for their widgets? Did people actually start testing their interfaces with 100 dpi fonts? Etc.
In the Free Software/Open Source world - such tests come for free. People use the software with all sorts of configurations and report problems.
Not to mention Qt (And other modern toolkits), unlike Windows, uses pure logical layouts and handles font sizes/etc very well.
Because changing the desktop means very little, when Joe Average's day still involves dealing with 10 different programs, using 6 fundamentally different widget sets, 8 fundamentally different keyboard shortcut sets, and 4 different ways of even persisting his preferences.
That's exactly the purpose of KDE. Creating a consistent GUI to do all those things. KDE is slowly getting rid of the GUI concept of "application", integrating capabilities to run software in contexts of all apps and windows (KPart/IOSlave technologies). KDE also has a very consistent default keyboard shortcut setup.
KDE is not about Gtk+ integration and consistency, but about internal integration and consistency (even though some projects to similarize do exist).
A lot of Windows's or a Mac's appeal doesn't come just from the way the desktop looks, nor from their particular flavour of widgets. It comes from the fact that everything running on it has the same standardized interface.
KDE is now more uniform and consistent than Windows and the vast amounts of inconsistent 3rd party apps. As for Macs, I haven't tried - but its probably hard to force UI guidelines/etc on 3rd party companies as you can force them with Free Software (simply modify any inconsistent application to follow the guidelines).
The way a Windows scroll bar or file open dialog works isn't perfect. (I actually prefer the Motif scroll bars.) But you can learn to use it _once_ and then apply that knowledge instinctively in all programs, from now until kingdom come.
Oh, I haven't seen my KDE scrollbar changing across applications.
Basically what I'm saying is: KDE is good and fine, and optimizing it doesn't hurt, but... IMHO what would really do Linux a world of good is enforcing a consistent interface across _all_ widget sets. Drag the good Qt, KDE, Gnome, Motif/Lesstif, GTK, etc people into a room, and don't let them out until they can aggree on a common interface standard
You can always use themes and such to make Gtk+/KDE look and behave similar. However, you're really supposed to be able to get along with just one of the toolkits - not having to worry about such inter-toolkit consistency.
A closed-source license.
Qt is also distributed under the GPL.
He is a Free Software advocate.
Everyone seems to be inaccurate about what exactly Stallman's visit came to advocate. Human lives are saved and lost on literal accuracy - please attempt to be accurate.
Isn't the Indian equivalent of the US president the Prime Minister?
Most people have replied with answers of the Open Source idealogy.
Open Source is a coherent and constistent philosophy of software development. Open Source holds to the goal of creating good software, with code sharing being the best mean towards that goal.
Since this article is about Richard Stallman, it is probably also appropriate to respond with the answer of the Free Software idealogy. Free Software is also a coherent and consistent philosophy - not of software development, but of freedom of information in general. Unlike Open Source, Free Software holds to the goal of individual/society Freedom, with good software resulting merely as a byproduct. In other words, Free Software means that even in case properiatly-licensed software offers a significant practical benefit to the alternate piece of Free Software, one should use the Free Software alternative - in order to not sign himself to secrecy against all of his peers.
Under the philosophy of Free Software, its simply and utterly unacceptable for someone to sign an NDA, or to restrict the changing or sharing of software. Forcing people to keep secrets from others is considered a crime against everyone in society.
It is therefore easy to envision how the GPL was created. The GPL is not about less restrictions, but about attempting to minimize the ability of others to restrict information sharing or impose secrecy.
Two executables can later load the same DLL's and hand control to them.
Under the hood of the COM objects, this is pretty much what happens.
CoLinux does not access hardware directly.
It uses the API's of the host OS.
It can mount its own Filesystems on block devices that are actually files on the host OS.
By writing a virtual file system driver that simply uses the host OS FS api's, you can "natively" access the Windows file system in the coLinux binaries. This means that Linux will access the NTFS data via Windows, and it can have its own ext2 block-device-over-file as well.
This is quite powerful and much nicer than cygwin which requires a lot of work per application ported.
Well, ofcourse since Linux runs in ring0 it can trash Windows.
If Windows trashes the system then you're screwed whether or not you run CoLinux on it.
The idea is that CoLinux does not do any I/O or have any drivers (which removes the dangerous part) nor does it touch physical memory in a way that's likely to interfere with Windows.
All physical memory is allocated from Windows via Windows' API's and only in a very extreme bug could the Linux virtual page tables be messed up so that they end up pointing at Windows pages and those pages get messed up in a bad way by yet another bug.
Most CoLinux crashes yield a double-fault which is handled by special code that can safely shut down the CoLinux virtual box which is totally harmless to the hosting Windows.
To actually crash Windows in CoLinux is very unlikely.