You will need to pay the MSDN License... which could just as well be called MSD License, given the amount of information and stuff that's only available for MSDN subscribers..
..as far as I can tell. When I was a kid, there was a lot of books of BASIC programming for kids in the local libs and bookstores and stuff.. (ok, you had to search the bookstores pretty carefully but..)
Nowadays, it seems that there are almost no "fun" programming books, that don't try to go to nasty details, but simply give you something to play with.
It might partially be that modern operating systems don't provide such easy environments to start programming as the BASIC interpreters used to be in every imaginable computer, and modern operating systems are somewhat more complicated to deal with.
Another possibility is that expectations of wannabe programmers are so much higher, that the only option is to write the book to look professional. No idea. I've wondered your question and mine for quite some time now, and don't see a reason. Could write an easy programming book for some of the scripting languages ofcourse, maybe something with simple text-adventures or something..
There are really really simple books ofcourse, but
those usually give you simple constructs, and no example code to play with. One nice thing was when I found an old LISP book from the local library, from about the era you describe. Even if it was this kind of "what LISP is about book" it had source code for meta-circular stuff and all.
(Have to add that SICP ofcourse does have that too, but SICP is not at all that simple book for a kid to read, but instead more of academic book.)
Anyone any ideas? Is it just that programming languages today are so hard that the people who used to write those nice books with example programs and all have lost their clue about programming?
Best games are those, where you won't try the same level twice, because the whole game map is generated randomly (up to certain rules ofcourse) and if you ever happen to die, that's permanent.
This doesn't naturally make it any easier to complete a game. Indeed, it makes it a lot of harder. But it makes extracting FUN easier, since you don't have to play the same 25 levels just to discover something new (or replay the same level 99,5 times).
Ok, the "X" example might be a bad one (and indeed I generally dislike identifiers that are two short to be descriptive, although in the particular case I had this, an uppercase X could not have possibly meant anything else but the Xserver interfacing object, and it was used extensively, which was actually the fault of the stupid interface, which I had nothing to say about anyway) but at least local one-letter variables are IMHO just fine in many places (that is not the same as "in most places" though). There are valid reasons to call something counter, but no professional programmer would have any trouble reading code where you have say, two coordinates, named "x" and "y" and an iteration variable "i" to iterate over an array.
I agree that one should think carefully before using short variables, but there are a lot of cases where using longer ones just doesn't make sense. Concrete (although trivial) example (in Scheme):
(define (pow2 x) (* x x))
There is simply no reason why this simple function would need a longer variable name than "x". The question is, can I use short variable names, and still write code that others can understand, or should I opt for longer names just for the sake of readability. For a function shorter than say, 5 lines, anybody can read it independent of the length of variable names (as long as you don't deliberately try to fill the lines ofcourse). In fact, it might well be harder to read, were longer names used, because the overall code would be longer. (In Java it often happens that you have to cut a single function call to multiple lines simply because you have to deal with extensively long identifier names. Ofcourse "import" can solve part of this, but then the reader of the code has to know what's imported if you ever have two classes with the same basename, which again is often impossible to prevent, even with base J2SDK.)
I agree though, that "Foobar" and "foobar" could just as well be made something like "foobar" and "foobar_obj" or what ever naming convention one happens to prefer. Experience has shown that a lot of people seem to like the "turn the first character to lower-case" convention.
PS. I realize perfectly well that the larger your codebase, and the more you have people working on it, the more descriptive names you need.
I am a programmer, and I can tell that case-sensitivity has other benefits too.
You don't need to care about the LOCALE settings or other such things. Either something is the same as something else, or it is not. You don't need to care if the compiler actually accepts the source with the right character set.
In some cases, it is very useful to be able to use the same identifier in several different cases. One example is having a class "Foobar", an instance of which you can name "foobar", and it's clear what class it belongs, but you still have a separate identifier.
This is not directly related to Java, but sometimes you want to have a short identifier for something that's used a lot. Say, you have a global object which talks to an Xserver. If you need to use that in many places, it's nice to name it "X" which is easy to understand, but "x" is a common variable name for short-lived variables, and you don't want it to be the same identifier as "X". Without case-sensitivity, you can't really use one letter globals, because one letter variables are the ones people will be using the most. With case-sensitivy, you can use just the uppercase for globals, and there's no problem. (whether globals are a good idea at all is another subject, and depends on the language and type of program one is writing in/for)
Case-insensitivity is probably the single most annoying thing with otherwise decent languages such as Scheme. In case-sensitive languages, errors in casing are usually catched by a compiler. With case-insensitive languages it's easy to make errors that are not catched, because the different looking identifiers are actually the same.
Ok, so there was this Slashdot article which among other things links to this other article which basicly says that they are checking *BSD codebase too.
They actually mention suing *BSD users too: "With our limited energies and what our guys are going through, we probably won't file any suits against BSD until sometime in the first half of next year."
I think it's SCO who is spreading most of the FUD here.
Once you have two servers that each to this, and someone sends a big message with forged headers (or from either of the servers) you have a loop.
I'm not really into bounces, since they have the habbit of developing into loops, which have the habbit of causing problems with free space on server..
Let's see.. in Finland, you usually buy a phone first, then get the carrier separately (although you can get both from the same place if you want). It's a little hard to compare prizing since the set of available phones is different but Nokia 6800 costs about 320e.. which is pretty much the same prize that's listed in the article..
So this does mean that you pay that prize once, and the phone is forever yours and you can switch it from carrier to another just by swapping the SIM card, right?
Btw, when cell phones where new, there was this ideology to sell a phone with a given prize only if you took the service from a given carrier at the same time... well.. doesn't happen anymore, thanks to some complaints from people and then a court ruling that it's against local laws.. has probably something to do with the fact that I've never heard anyone have any problems ordering a PC without an operating system but that's another story..
Now, if someone could just explain the "plan" thing to me once and for all:)
That's why nobody wants to test the GPL in court. Either way, it jeopardises the whole concept of payware.
Sorry about this, but I'd like your comments why SCO seems to want to test GPL in court. I can think of points why RedHat or IBM might not care, but why SCO wants it there? It might be that they are hoping that it never happens but...
The parent might be funny, but indeed, this might have something to do with SCO. Now that SCO has started it, smaller players might be more willing to try violating GNU GPL, and hope to get away with it.
The more companies actually do it, the more doubt it will cause that there is something wrong with either the GPL or software under it, and the harder OSS community will have to fight to defend it's ideas, software and (hopefully not) users.
Keep faith. This might, after all, ultimately lead to a revolution. =)
Well, I've done CORBA for work, play'ed around with all kinds of other RPC systems, programmed with a quite a lot of languages, and after some hobby research and all kinds of strange projects, I've come to the following conclusion personally:
There is one good RPC system, and it's called HTTP. It works wonderfully when you can generate stuff from a database into some text-representation.
There are a lot of bad ones, which mostly have the same thing in common: It is NOT a good idea to make a remote resource act like an object. It just doesn't work well. To get an impression that it works well, you need a huge bloated library, so you can pretend that everything works, until your network breaks and you have to deal with all the shit yourself anyway, but now add the complexity of the RPC system to the mix.
The thing is, when you design to work with a very simple system, either HTTP or something similar built on top of TCP directly, you end up with design, where the network is a natural part of the system. When you build something on top of a generic RPC system, you just add a layer of indirectness, which makes a good design much harder to get. In addition, when you restructure your data into text-representation (or other simple representation), you usually end up doing it in the right place, because it's usually the only place where such representation can be handled in a sane way.
That's my 1 cent about RPC. The other 1 cent deals with objects. Objects are nice, if you don't have 1) database or 2) proper functions. When you have a (relational) database, you end up with something like objects anyway, when you build a good database access layer. For many things this is what you would want to do anyway, with the added benefit that you never need to care about object references. You just tell the system how to find/alter what you need.
For the functions, as soon as you have first-class functions, objects no longer make much sense, as it takes about 15 seconds to build an object system on top of these functions. Most of the time you don't want object anyway, as you usually want functions and data instead. Learn LISP. It is more useful today than ever before. If there's something wrong with existing dialects, then help build a better one.
As for your requirements: You could use TCP directly, but you need encryption, so add ssl or something. Authenticate the connection or something, the encryption should handle rest of the integrity (this is pretty much a cipher question). Build a simple protocol with no tweaks and leave the extensibility there. If you want, you could send XML anyway, if you use zlib or something to compress it. Depending on your data, it might be the easiest thing to parse anyway.
Separate the protocol layer, have it timeout and catch TCP failures, and automatically reconnect (same or other server), and you have the time-sensitivity. If you need more, send requests to multiple servers, and handle them with the one that answers first. Aim for stateless protocol, and it becomes easier. TCP and SSL are pretty platform independent, so unless your protocol is really bad that shouldn't be a problem. Now, you basicly want this all for every application in existence.
Forget the objects, they just make life a lot harder. Use cookies and numerical identifiers if you really need to. A lot of things look like they needed OO-RPC, but to this day I've not seen a single one where it really made sense. Doesn't even speedup development in the long run..
VB has it's uses. Basicly, the best part of VB is glueing together components written in some other language (most often C++). It's just one of the easiest way to glue.
I'd say that only being able to program in VB is useful, but to actually get something complex done, you either need someone that can do controls for you or you have to know how to use the Visual C++ wizards to create you the control you can then add some C++ into.
This is actually must more nice model of working than it sounds. At all times you are either in component programming mode, or application programming mode, composing applications from those controls in VB.
You can't do a datastructure in VB? Write a control. You need some UI control VB doesn't supply? Write a control. VB too slow for some calculation? Write a control. Want automatic
layouts into VB (and don't want to do them in
Basic)? Just write another control.
The thing is, alone VB is just a toy, but the component model makes it nice. It's the same thing with the HTML thing. You can still have your real code in COM controls, but instead of VB you can now also use HTML to create the user interface. Big deal, this is just what component architectures are ment for.
You just need a crack that in addition to going around the virtual drive checking routine, replaces the routine which replies to servers query of the checksum, either returning the correct (original) checksum it it's static, or using the unmodified binary to calculate the checksum.
While this is a bit harder to do than just jmp:ing over the checking routine, there's no fundamental reasons why you would have to return the real checksum of the binary. It's just more work for the cracker.
Actually, even adding something like PunkBuster there to do the checksumming doesn't help. There's no reasons why ANYTHING on your computer could be trusted by the server. It's just a matter of adding yet more things that must be cracked before the game works.
That said, this whole thing is ridiculous. What's the point of playing games on PC if you have to search for the stupid CD. Game makers that try to force one to do this are just trying to kill the PC gaming. Those people that can't use virtual drives have most likely already gone to consoles.
There is a problem with Winamp2 (latest). It sometimes has the video flipped vertically. Now there is a switch to support old codecs where this is a problem but I've found one big problem with it: regardless of the switch setting, divx311alpha is always vertically flipped. Same codec works perfectly with old media player (the mplayer2.exe you find in "c:\program files\windows media player")
It's a shame, since Winamp's a nice program and divx311alpha has good quality and was used quite extensively at some point. Some people still believe it's the best codec ever.
Re:I think my form of encryption is better
on
RSA-576 Factored
·
· Score: 4, Informative
For people that think they are now going to generalize this into some kind of general purpose encryption scheme, I'd like to add that OTP works ONLY when it's "one time" pad. That is, once you try to reuse any or all of the pad in any way, you lose the property of uncrackability and it becomes a statistical problem to solve the message.
In plain english, this means that OTP must be unique and truly random and have the same length as the message. While the encryption is uncrackable, the problem of transmitting proper OTPs remains.
Not to say that it couldn't be useful for some special cases, but for general purpose encryption, no.
The thing is, if a game costs $2, you just might want to pay for the legal right to play the game, instead of loading it from a warez site. If it costs $40, you probably can't afford to try if the game is worth buying, and once you've already got the game, why bother to buy it anymore..
This makes no sense. There's no way an ISP can monitor the transfer of copyrighted materials without blocking all encrypted traffic, specifically including SSH (sftp transfers files, but I'd imagine there are other reasons why blocking SSH is not a good idea, duh.) and HTTPS (which is pretty useful for commercial transactions too).
Even transfer of non-encrypted material is practically impossible monitor ofcourse, given the wide range of different protocols, and because it's impossible to accurately identify illegal filetransfers. The only solution I can see that could be used to implement this, would be to ban the use of all TCP/IP, except some explicitly white-listed set of web pages.
For someone able to program, putting a simple content management system (which does exactly what is needed and nothing more) is not that hard. I'd expect that to take at most three days with something like PHP, at least if you are going to host the site on a server with a decent RDBMS.
The trouble is that while it's easy to create a personalized system, is much harder to create an universal one. Most of the systems that would have the set of features you need, also have everything else under the sun, which usually makes the system more complicated to use.
Actually, I've been missing a simple, generic system with some kind of plug-in style system. The trouble is, the interface to add/write plug-ins whould have to be simple enough.
The problem with PHPNuke and the likes is that it's often easier to write a custom system than setup a nuke-system.
I've tried creating a platform a couple of times, mostly with PHP. The most successful (for my personal use, not really suitable for releasing) was a fully custom HTTP server written in Ruby. (ofcourse I had apache as proxy and static-content server, althought the server could handle all common web-browsers directly as well).
This allowed an architecture where I could write a simple class everytime I needed a new feature. No API interfacing glue, nothing, just a class that has methods for some attributes like titlebar and another which would return the actual page, optionally a POST handler.
I'd actually love to work on something like this, but unfortunately I have no server available these days where I could have any dynamic content mechanism, let alone an RDBMS.
Which makes me wonder, are there any offline CMS in open source, that would be worth trying. Fog Creek has Citydesk, but that's commercial and more importantly, doesn't run on Linux.
Friend of mine wanted to remove WindowsMediaPlayer9 (or whatever the latest) from his Win2003Server box, and guess what was needed: just get the standalone version (from microsoft.com) and use the.inf from that to uninstall.
After that you still have Windows Media Player 6. If you uninstall that too, then you also have to get rid of Windows Media Player 5, since they are all there.
Same procedure works in XP I think. The other option is to delete files and clean-up registry manually. Part of OS... yeah right..
They might view finding and making public security holes in the competition as a more valuable and profitable exercise than securing their own OS and software.
If this is what they think, they go wrong in two places. First one is obvious ofcourse, it won't make their own OS more secure, but there's more; if Microsoft invests energy to find bugs in OSS, they are working for the OSS community. If they publish the bugs (or even where they might be) they'll get fixed.
The trick is, when you have a closed source model, you are out-numbered almost certainly. If you are in this position you should NOT waste effort of your programmers on helping OSS community to find problems. Those problems can be fixed by some people, while other people continue to find problems in your closed source system, which you can't fix, 'cos you've just assigned all your programmers to find problems in competitors products.
Ofcourse Microsoft is large enough to invest in both, but the most they can win is a small short-term PR victory. In the end they'd help OSS. If they understood the nature of OSS, they'd just accept it's existence, and spend to effort to fight it. Resistance is futile anyway..
I still prefer having a regular phone (and the old one as a spare). I bet you can't take the SIM out of a disposable and replace it with someone elses temporarily because that someone else just run out of his battery..
Then you weren't paying attention. 2.4.x was a complete wreck, and everyone complained. I still remember the infamous Thanksgiving "turkey" kernel that randomly corrupted ext3 partitions.
I know good Unix admins and good Windows admins and neither of them puts fresh stuff on production machines.
The base definition of an operating system is the kernel running it, dummy. Linux is the system operating my devices and letting me operate my computer.
I'd say the based definition of operating system is an abstraction layer between user applications and the hardware. Kernel is one part of this, but so are libraries and basic utilities. You could even say that "the Linux kernel provides hardware abstractions and device drivers for the rest of the GNU/Linux operating system".
Windows also has permissions. Every single Windows network I've ever run or worked with operated the same way.
I agree here. The problem is not that there was no permissions. Both systems have equally bad permission framework (and on theoretic level I'd vote in favour of Windows if I'd have to). Users have too much permissions by default, permissions are too limited and fine-grained, and programs run with the full priviledges of the user running them.
The main problem however, is how these systems are run, and whether those permissions can be enforced reliably. First is question of management, second is question of code quality.
Another "GNU/Linux" weenie. Here's the part where someone mods me down instead of posting in disagreement.
This is a disagreement was posted from a GNU/Linux-workstation.
This studies the costs between.NET and J2EE, not really Windows and Linux.
One could also say that it compares native Windows and J2EE, but Java is by no means a native system to Linux, which is to say that this is like comparing apples with oranges.
Having supported a largish J2EE application, I can tell that the it's equally awful platform, whether it runs on Windows or UNIX. I'd suggest that if one compared J2EE on Windows to J2EE on UNIX, UNIX would probably win.
I agree with you here.
This might even be a Good Thing after all, given that many ordinary people that normally might not care about things like DMCA might actually check the page out of curiosity, and see what it is..
So basicly, I'm saying that Google blocking a site because of DMCA might actually result in growing anti-DMCA feelings among normal people.
Slashdot Mirror
You will need to pay the MSDN License. .. which could just as well be called MSD License, given the amount of information and stuff that's only available for MSDN subscribers..
Nowadays, it seems that there are almost no "fun" programming books, that don't try to go to nasty details, but simply give you something to play with.
It might partially be that modern operating systems don't provide such easy environments to start programming as the BASIC interpreters used to be in every imaginable computer, and modern operating systems are somewhat more complicated to deal with.
Another possibility is that expectations of wannabe programmers are so much higher, that the only option is to write the book to look professional. No idea. I've wondered your question and mine for quite some time now, and don't see a reason. Could write an easy programming book for some of the scripting languages ofcourse, maybe something with simple text-adventures or something..
There are really really simple books ofcourse, but those usually give you simple constructs, and no example code to play with. One nice thing was when I found an old LISP book from the local library, from about the era you describe. Even if it was this kind of "what LISP is about book" it had source code for meta-circular stuff and all. (Have to add that SICP ofcourse does have that too, but SICP is not at all that simple book for a kid to read, but instead more of academic book.)
Anyone any ideas? Is it just that programming languages today are so hard that the people who used to write those nice books with example programs and all have lost their clue about programming?
This doesn't naturally make it any easier to complete a game. Indeed, it makes it a lot of harder. But it makes extracting FUN easier, since you don't have to play the same 25 levels just to discover something new (or replay the same level 99,5 times).
I agree that one should think carefully before using short variables, but there are a lot of cases where using longer ones just doesn't make sense. Concrete (although trivial) example (in Scheme):
There is simply no reason why this simple function would need a longer variable name than "x". The question is, can I use short variable names, and still write code that others can understand, or should I opt for longer names just for the sake of readability. For a function shorter than say, 5 lines, anybody can read it independent of the length of variable names (as long as you don't deliberately try to fill the lines ofcourse). In fact, it might well be harder to read, were longer names used, because the overall code would be longer. (In Java it often happens that you have to cut a single function call to multiple lines simply because you have to deal with extensively long identifier names. Ofcourse "import" can solve part of this, but then the reader of the code has to know what's imported if you ever have two classes with the same basename, which again is often impossible to prevent, even with base J2SDK.)
I agree though, that "Foobar" and "foobar" could just as well be made something like "foobar" and "foobar_obj" or what ever naming convention one happens to prefer. Experience has shown that a lot of people seem to like the "turn the first character to lower-case" convention.
PS. I realize perfectly well that the larger your codebase, and the more you have people working on it, the more descriptive names you need.
Case-insensitivity is probably the single most annoying thing with otherwise decent languages such as Scheme. In case-sensitive languages, errors in casing are usually catched by a compiler. With case-insensitive languages it's easy to make errors that are not catched, because the different looking identifiers are actually the same.
My .02 euros. YMMV.
They actually mention suing *BSD users too: "With our limited energies and what our guys are going through, we probably won't file any suits against BSD until sometime in the first half of next year."
I think it's SCO who is spreading most of the FUD here.
I'm not really into bounces, since they have the habbit of developing into loops, which have the habbit of causing problems with free space on server..
So this does mean that you pay that prize once, and the phone is forever yours and you can switch it from carrier to another just by swapping the SIM card, right?
Btw, when cell phones where new, there was this ideology to sell a phone with a given prize only if you took the service from a given carrier at the same time... well.. doesn't happen anymore, thanks to some complaints from people and then a court ruling that it's against local laws.. has probably something to do with the fact that I've never heard anyone have any problems ordering a PC without an operating system but that's another story..
Now, if someone could just explain the "plan" thing to me once and for all :)
Sorry about this, but I'd like your comments why SCO seems to want to test GPL in court. I can think of points why RedHat or IBM might not care, but why SCO wants it there? It might be that they are hoping that it never happens but...
Keep faith. This might, after all, ultimately lead to a revolution. =)
There is one good RPC system, and it's called HTTP. It works wonderfully when you can generate stuff from a database into some text-representation.
There are a lot of bad ones, which mostly have the same thing in common: It is NOT a good idea to make a remote resource act like an object. It just doesn't work well. To get an impression that it works well, you need a huge bloated library, so you can pretend that everything works, until your network breaks and you have to deal with all the shit yourself anyway, but now add the complexity of the RPC system to the mix.
The thing is, when you design to work with a very simple system, either HTTP or something similar built on top of TCP directly, you end up with design, where the network is a natural part of the system. When you build something on top of a generic RPC system, you just add a layer of indirectness, which makes a good design much harder to get. In addition, when you restructure your data into text-representation (or other simple representation), you usually end up doing it in the right place, because it's usually the only place where such representation can be handled in a sane way.
That's my 1 cent about RPC. The other 1 cent deals with objects. Objects are nice, if you don't have 1) database or 2) proper functions. When you have a (relational) database, you end up with something like objects anyway, when you build a good database access layer. For many things this is what you would want to do anyway, with the added benefit that you never need to care about object references. You just tell the system how to find/alter what you need.
For the functions, as soon as you have first-class functions, objects no longer make much sense, as it takes about 15 seconds to build an object system on top of these functions. Most of the time you don't want object anyway, as you usually want functions and data instead. Learn LISP. It is more useful today than ever before. If there's something wrong with existing dialects, then help build a better one.
As for your requirements: You could use TCP directly, but you need encryption, so add ssl or something. Authenticate the connection or something, the encryption should handle rest of the integrity (this is pretty much a cipher question). Build a simple protocol with no tweaks and leave the extensibility there. If you want, you could send XML anyway, if you use zlib or something to compress it. Depending on your data, it might be the easiest thing to parse anyway. Separate the protocol layer, have it timeout and catch TCP failures, and automatically reconnect (same or other server), and you have the time-sensitivity. If you need more, send requests to multiple servers, and handle them with the one that answers first. Aim for stateless protocol, and it becomes easier. TCP and SSL are pretty platform independent, so unless your protocol is really bad that shouldn't be a problem. Now, you basicly want this all for every application in existence.
Forget the objects, they just make life a lot harder. Use cookies and numerical identifiers if you really need to. A lot of things look like they needed OO-RPC, but to this day I've not seen a single one where it really made sense. Doesn't even speedup development in the long run..
I'd say that only being able to program in VB is useful, but to actually get something complex done, you either need someone that can do controls for you or you have to know how to use the Visual C++ wizards to create you the control you can then add some C++ into.
This is actually must more nice model of working than it sounds. At all times you are either in component programming mode, or application programming mode, composing applications from those controls in VB.
You can't do a datastructure in VB? Write a control. You need some UI control VB doesn't supply? Write a control. VB too slow for some calculation? Write a control. Want automatic layouts into VB (and don't want to do them in Basic)? Just write another control.
The thing is, alone VB is just a toy, but the component model makes it nice. It's the same thing with the HTML thing. You can still have your real code in COM controls, but instead of VB you can now also use HTML to create the user interface. Big deal, this is just what component architectures are ment for.
While this is a bit harder to do than just jmp:ing over the checking routine, there's no fundamental reasons why you would have to return the real checksum of the binary. It's just more work for the cracker.
Actually, even adding something like PunkBuster there to do the checksumming doesn't help. There's no reasons why ANYTHING on your computer could be trusted by the server. It's just a matter of adding yet more things that must be cracked before the game works.
That said, this whole thing is ridiculous. What's the point of playing games on PC if you have to search for the stupid CD. Game makers that try to force one to do this are just trying to kill the PC gaming. Those people that can't use virtual drives have most likely already gone to consoles.
It's a shame, since Winamp's a nice program and divx311alpha has good quality and was used quite extensively at some point. Some people still believe it's the best codec ever.
In plain english, this means that OTP must be unique and truly random and have the same length as the message. While the encryption is uncrackable, the problem of transmitting proper OTPs remains.
Not to say that it couldn't be useful for some special cases, but for general purpose encryption, no.
The thing is, if a game costs $2, you just might want to pay for the legal right to play the game, instead of loading it from a warez site. If it costs $40, you probably can't afford to try if the game is worth buying, and once you've already got the game, why bother to buy it anymore..
Even transfer of non-encrypted material is practically impossible monitor ofcourse, given the wide range of different protocols, and because it's impossible to accurately identify illegal filetransfers. The only solution I can see that could be used to implement this, would be to ban the use of all TCP/IP, except some explicitly white-listed set of web pages.
For someone able to program, putting a simple content management system (which does exactly what is needed and nothing more) is not that hard. I'd expect that to take at most three days with something like PHP, at least if you are going to host the site on a server with a decent RDBMS.
The trouble is that while it's easy to create a personalized system, is much harder to create an universal one. Most of the systems that would have the set of features you need, also have everything else under the sun, which usually makes the system more complicated to use.
Actually, I've been missing a simple, generic system with some kind of plug-in style system. The trouble is, the interface to add/write plug-ins whould have to be simple enough.
The problem with PHPNuke and the likes is that it's often easier to write a custom system than setup a nuke-system.
I've tried creating a platform a couple of times, mostly with PHP. The most successful (for my personal use, not really suitable for releasing) was a fully custom HTTP server written in Ruby. (ofcourse I had apache as proxy and static-content server, althought the server could handle all common web-browsers directly as well).
This allowed an architecture where I could write a simple class everytime I needed a new feature. No API interfacing glue, nothing, just a class that has methods for some attributes like titlebar and another which would return the actual page, optionally a POST handler.
I'd actually love to work on something like this, but unfortunately I have no server available these days where I could have any dynamic content mechanism, let alone an RDBMS.
Which makes me wonder, are there any offline CMS in open source, that would be worth trying. Fog Creek has Citydesk, but that's commercial and more importantly, doesn't run on Linux.
Friend of mine wanted to remove WindowsMediaPlayer9 (or whatever the latest) from his Win2003Server box, and guess what was needed: just get the standalone version (from microsoft.com) and use the .inf from that to uninstall.
After that you still have Windows Media Player 6. If you uninstall that too, then you also have to get rid of Windows Media Player 5, since they are all there.
Same procedure works in XP I think. The other option is to delete files and clean-up registry manually. Part of OS... yeah right..
If this is what they think, they go wrong in two places. First one is obvious ofcourse, it won't make their own OS more secure, but there's more; if Microsoft invests energy to find bugs in OSS, they are working for the OSS community. If they publish the bugs (or even where they might be) they'll get fixed.
The trick is, when you have a closed source model, you are out-numbered almost certainly. If you are in this position you should NOT waste effort of your programmers on helping OSS community to find problems. Those problems can be fixed by some people, while other people continue to find problems in your closed source system, which you can't fix, 'cos you've just assigned all your programmers to find problems in competitors products.
Ofcourse Microsoft is large enough to invest in both, but the most they can win is a small short-term PR victory. In the end they'd help OSS. If they understood the nature of OSS, they'd just accept it's existence, and spend to effort to fight it. Resistance is futile anyway..
Ofcourse if you have a SIMLOCKed joke..
I know good Unix admins and good Windows admins and neither of them puts fresh stuff on production machines.
The base definition of an operating system is the kernel running it, dummy. Linux is the system operating my devices and letting me operate my computer.I'd say the based definition of operating system is an abstraction layer between user applications and the hardware. Kernel is one part of this, but so are libraries and basic utilities. You could even say that "the Linux kernel provides hardware abstractions and device drivers for the rest of the GNU/Linux operating system".
Windows also has permissions. Every single Windows network I've ever run or worked with operated the same way.I agree here. The problem is not that there was no permissions. Both systems have equally bad permission framework (and on theoretic level I'd vote in favour of Windows if I'd have to). Users have too much permissions by default, permissions are too limited and fine-grained, and programs run with the full priviledges of the user running them.
The main problem however, is how these systems are run, and whether those permissions can be enforced reliably. First is question of management, second is question of code quality.
Another "GNU/Linux" weenie. Here's the part where someone mods me down instead of posting in disagreement.This is a disagreement was posted from a GNU/Linux-workstation.
It's kinda like "client/server", then "decentralized" then "client/server" then "decentralized" then "client/server" etc..
History is good at repeating transitions between different computing paradigms and back..
One could also say that it compares native Windows and J2EE, but Java is by no means a native system to Linux, which is to say that this is like comparing apples with oranges.
Having supported a largish J2EE application, I can tell that the it's equally awful platform, whether it runs on Windows or UNIX. I'd suggest that if one compared J2EE on Windows to J2EE on UNIX, UNIX would probably win.
I agree with you here. This might even be a Good Thing after all, given that many ordinary people that normally might not care about things like DMCA might actually check the page out of curiosity, and see what it is..
So basicly, I'm saying that Google blocking a site because of DMCA might actually result in growing anti-DMCA feelings among normal people.
Might be that I'm just dreaming though..