I'll say what I said then when I was on top of it: Programming MUDs is one of the best ways to learn how to program. First you need to understand how the MUD works internally, then you add features to it until you actually have to refine it so that your feature can be implement it. And oh yeah, you don't have to be an artist or a mathematician to program it, you just need some fantasy and understand a fair amount of logic.
Try that for 3000 clients and your performance is toast !
Cluster your export points
Use hardware accelerated encryption devices
Ask yourself: do these 3000 clients really need access? And what part of the local file system do they need access to? I realize that querying 3000 users for their purposes is a bloody hard job now, but it should have been done in the first place. Follow the principle of least privilege.
For an organization with 3000 external clients, security shoult be at the top of the TODO-list. Finding a hacker/spoofer among 3000 clients is like finding a needle in a haystack. If this scenario is yours, then please reconsider some major security face lifts...
A hole in one every time. You can't beat such a record with SMB (Windows shares) w/o having an MSCE (connecting win98 machines with windows 2000 is not always a "turn key" thing.. *grumble* what's up with those Redmond freaks?)
There are a lot of sysadmins here, but I have a hunch that there are more newbies and sysadmin wannabees here.
Also, there are many Linux -> FreeBSD converts that could use this information. (I don't know how similar NFS on those platforms are, but I'm sure there are some differences).
If you want components isolated, then you'll probably have to run them in a child process or at the very least its own thread.
In the process case, calls to the component and events from it must be marshalled in some way across the process boundaries. Pretty much like RPC but locally (on Windows it's called LPC - Local Procedure Calls, on Solaris it's called doors). This is CPU intensive. Sharing data between components will also be very time/CPU consuming since data must be marshalled back and forth. And how can you share data between processes where all changes are visible in all processes without a very high overhead?
In the thread case, calls to the component and events from it must be synchronized in some way. An event for instance cannot be delivered until the receiver is ready. Of course you could use event queues, but you'd have to protect them with mutexes. With a lot of components, there will be a lot of lock/unlock scenarios and it will slow things down. And the worst case scenario is when one component crashes during a lock.. Who's gonna unlock it? Designing a threaded architecture requires a lot of thought and skill.
I'd say threading and multiprocessing should only be used when absolutely necessary. Bad use of both technologies will punish you later...
Re:Guys stop bashing Miguel for going with .NET
on
Coding with KParts
·
· Score: 2, Insightful
ActiveX development is shiteasy today. ATL makes it a breeze. In fact, when I do GUI stuff, I try to make most of my stuff ActiveX components so that I can reuse it later. And the good part is that the overhead of ActiveX components is very small. Sometimes it's even better than "ordinary" windows/window classes since you can make ax controls windowless.
Yes you are attacking by saying that they have done nothing for the past 10 years.
They have been constantly upgrading the GNU tools, been busy putting together a new kernel with their tools (Mach + tools -> Hurd as per the GNU project mission statement), contributing with a desktop system/platform for the GNU operating system (GNUStep), updating emacs, the editor for the GNU operating system, as time passes by, and loads of other stuff. Take a look at GNU Projects and GNU Software too see what the GNU project has been doing for ther last decade. These projects are both directly and indirectly supported by the FSF in various ways (money, hardware or whatever they're donated).
What Linux distributions and other "projects" have been doing is using GNU stuff all along. Which is per definition ok. But I don't see why FSF and related GNU projects shouldn't be able to take some credit. It's not like their demanding money, advertising or anything. They want recognition for their work.
Some argues that MIT/X Consortium and Perl org should get equally as much recognition. The fact is that they do. The only reason why FSF wants it spelled GNU/Linux is because Linux would not run without GNU. The operating system would NOT be complete. You can run stuff without perl, you can run stuff without X, but you can't run stuff without linkers, loaders, and shells (at least not efficiently). Sure, rip out GNU stuff and put in BSD, but then it would be BSD/Linux.
If I was a BSD developer, and someone created an operating system by ripping out the GNU stuff and replacing it with BSD stuff, I'd be cranky too if someone called it "Linux". The voice of FSF in the Linux community should perhaps not always adhered to, but it should most definately be heard.
No you dillweed. The reason that Gnome gave FSF the copyright is that FSF can handle court cases when someone violates the GPL. Also, this is highly optional.
Gnome joined the GNU Project. The GNU project is lead by RMS. This is doesn't happen automatically by using the GPL. You have to do that actively. If you do that, then of course the project leader gets a piece of the action. I mean, it's Gnome which is a part of the GNU Project, not the other way around. If the Gnome people doesn't like this, they can bail out of the GNU Project.
Obviously the Gnome people saw a benefit in joining the GNU project. No one was forced to do it.
My point is that RMS/FSF/GNU has, under there own roof, produced negligable amounts of usefull code in the last decade.
Yes. It's your moot point. You have nothing to say about this. And I get pissed of every time people attack the FSF for no f*cking reason. Everything is done be free will. Let the Gnome people which actually DO something, decide whether FSF/GNU project is a good thing or not. You just have a problem with RMS (what I don't know, and I don't care).
I myself prefer BSD license before GPL, but I still respect the GPL, FSF and RMS. I don't have to stick a GPL on my code, I don't have to join the GNU project, and I don't have to give my copyright to the FSF. Know why? Because I'm free NOT do it, and RMS is not forcing me.
If it wasn't GNU that provided the tools, it would most likely have been BSD tools. Either way, the OS would not have been entirely Linux, and I bet that the BSD community would have claimed some credit for their work as well..
You didn't write the Linux kernel nor any GNU tool, so why are you whining? You're still using GNU stuff, aren't you? If you are so fed up with GNU, why don't you install FreeBSD instead? Either way, stop whining.
Microsoft put down a lot of money into their products. If they want money for it, and you want to use it, then pay up or shut up. If you don't pay for it, you cannot complain the slightest about their license.
You are however free not to choose Microsoft products. Then you certainly won't pay a dime to Gates. You're more likely to take away some profit from him.
If you deny it, then you are violating the license, and thus Microsoft can demand you to pay the license fee. If you don't you may end up paying a fine for "software theft".
I am not arguing what you believe is right. I agree with you that one should be able to buy the software and not a license to use it. I'd pay more for the software than the license. What I'm arguing is that you are not free to do this by law.
But you don't have to obey to these bloody licenses, there are much more software out there, that is not licensed this way. Anything licensed under BSD or GPL is a good start. Both allow you to do what you want with the software as long as you don't distribute it. The GPL denies certain things when distributing it (like NOT making the source freely available). BSD had an advertisment clause, but it is gone now, meaning you can do whatever you want with it. If this is the freedom you want, then go ahead and use this software instead.
For what its worth, you could print out the BSD kernel code, roll it and smoke it. No one is going to fine you for that! (unless you put something in the roll..;)
If I buy software I OWN it, I did NOT buy a license, no matter what they say, I bought SOFTWARE that I can do with as I please...it's frickin' MINE.
Not if you buy Microsoft software you don't. That's the point. You only buy a license to use it under their terms. What you say is irrelevant, you agreed to the EULA when you bought and installed the product. If you wan't to own the product, then don't buy Microsoft software.
And as for spying.. Are you out of your mind? Sure they could do that, but they could not use it in a court. Spying, or tapping, may ONLY be performed if a court order has been issued. Microsoft would get in serious trouble, probably more serious than this monopoly thing. Remember when Intel tried to push CPU identification numbers?
The gain of something is always measured against the risks and effort. In this case the risk is far too high as well as the effort.
I'm not pro-Microsoft, but sometimes these conspiracy theories are pretty lame. Perhaps you should think before you start shouting about things you KNOW NOTHING about?
How is that bad? Who's gonna fix your broken Windows but Microsoft? The source isn't open, so in this case you have to trust Microsoft to do it for you. If you don't trust them, then don't buy Windows (i.e. agree to their EULA). If you bought Windows, this is a pretty damn slick way to fix the machine, just as slick as apt-get, red carpet,/usr/ports or whatever.
RedHat has shipped bugs before, how come you're not stabbing them for their "Red Carpet" (or whatever they call it).
Well, Haskell cheats big time (and so do most other "pure paradigm" languages). Haskell uses something called monads for I/O. I never bothered to use monads since I used Haskell primarily for studying type systems, but I read something about Haskell having a "sublanguage" to manage I/O properly.
One thing that has "bothered" me is the GTK bindings for Haskell. How the h*ll can one describe a GUI interface using nothing but expressions? I guess I'll have to do some investigations one of these days..:)
I agree with you that C# is probably better for the "ordinary programmer". It's turing complete, it has a rich class library (pretty much like java), and it has the "smooth" C syntax;) Haskell on the other hand is very extreme in nature and requires some extreme thinking of an "ordinary programmer" since the ideas behind the Haskell language is fundamentally different from those behind C#. And I guess the same applies for a person who comes from a functional background that uses C# (or C, C++ and the like).
In your first example, it is possible for the compiler to interpret that in such a way as to make the code correct. That is, since x is returned, this object should be allocated space that outlives the function. I have no idea whether the c++ specs call for it to work this way, but if c# is purporting to be safe they certainly should do this. But is it possible to cover every way that an originally valid reference could be come invalid?
First of all, the compiler cannot make "intelligent" decisions about how you want the object to be used. The reason is basically because of side effects. Programming using side effects is basically the same thing as programming by maintaining state. Since we're maintaining states, the order of events (statements=memory access) is significant. (Think about it.. you cannot go to work before you have woken up:)
Same thing here. Memory access related stuff is *very* hard to optimize the way you describe. You'd have to find every corner case and you'd have to analyze the code thouroughly during compilation - a sort of runtime analysis. In this simple example, a compiler could easily trap it (some do warn). But there are more hard to spot errors which compilers cannot easily trap.
Anyhow, it is easier to specify simple rules which the programmer must adhere to, instead of making the compiler extremely complex. (Chances are that complex compilers produce more errors than you.) If you break the rules, it's your problem.
C# on the other hand manages memory accesses for you. In fact you never get to touch raw memory, unless you explicitly say so (and that memory will not be in the same "environment" as your managed memory). It can do garbage collections, memory compacting, dead data removal and all sorts of things, which is very hard (if not impossible) without an extensive runtime.
[OT Warning]:
Speaking of memory managed languages, Haskell is a language that hides basically all memory from you. It is purely functional, thus there is no such thing as "state". For a non-functional programmer, writing an application in terms of equations, expressions and pattern match rules can be... hm... an experience? Anyhow, since you do not have anything called state, the runtime can mix and match any evaluation as it is needed.
It can
delay evaluation, since the value may not be needed. If it is not needed, whats the point of evaluating it?
parallelize your code. Since the order of evaluation does not matter, expressions which do not depend on eachother, can be easily executed at the same time. Great potential for SMP usage there.
IIRC this act is based on the EU privacy directives. The goal is that all EU members shall implement a "compatible" act. In Sweden, these laws has already been implemented (some know them as PUL). Hopefully all EU members have implemented this real soon now.
How do we know you're not a terrorist unless we're allowed to place you under surveillance for 24 h/day?
That statement is basically the same as "Everybody is guilty, until proven innocent". I have not proved to anyone that I'm not a terrorist, so according to your view of things, I'm probably planning a massive attack against thousands of innocent lives.
Think before you call me a terrorist, you carnivorous monster.
at least all BSD's I've used (Net, Free, Open, BSD/OS) sucks LESS than any Linux distribution I've used (Debian, Redhat, Mandrake, SuSE, Caldera, the-photoshop-copycat-canadian-company-whose-name- I-cant-remember).
Have you even compared any BSD against a Linux distribution, or are just another clueless script kiddie that just cannot get the scripts to work in a BSD environment?
Inhouse software is great for development. Can you say "compiler backends"?
I've been hired by companies which are typically closed source companies, but still have used GPL'd stuff inhouse for development. And most of the time, the inhouse developers are good persons, and distribute the changes back to the community, eventhough they are not obligated. Pretty much BSD spirit.
I'll say what I said then when I was on top of it: Programming MUDs is one of the best ways to learn how to program. First you need to understand how the MUD works internally, then you add features to it until you actually have to refine it so that your feature can be implement it. And oh yeah, you don't have to be an artist or a mathematician to program it, you just need some fantasy and understand a fair amount of logic.
CircleMUD is what taught me a thing or two.
For an organization with 3000 external clients, security shoult be at the top of the TODO-list. Finding a hacker/spoofer among 3000 clients is like finding a needle in a haystack. If this scenario is yours, then please reconsider some major security face lifts...
Use IPSEC authentication (AH or ESP if you also need encryption). Doesn't get much more secure than that.. The rest is your fault.. ;)
A hole in one every time. You can't beat such a record with SMB (Windows shares) w/o having an MSCE (connecting win98 machines with windows 2000 is not always a "turn key" thing.. *grumble* what's up with those Redmond freaks?)
There are a lot of sysadmins here, but I have a hunch that there are more newbies and sysadmin wannabees here. Also, there are many Linux -> FreeBSD converts that could use this information. (I don't know how similar NFS on those platforms are, but I'm sure there are some differences).
It's like VMWare, but at the hardware level. (And better I suppose)
If you want components isolated, then you'll probably have to run them in a child process or at the very least its own thread. In the process case, calls to the component and events from it must be marshalled in some way across the process boundaries. Pretty much like RPC but locally (on Windows it's called LPC - Local Procedure Calls, on Solaris it's called doors). This is CPU intensive. Sharing data between components will also be very time/CPU consuming since data must be marshalled back and forth. And how can you share data between processes where all changes are visible in all processes without a very high overhead? In the thread case, calls to the component and events from it must be synchronized in some way. An event for instance cannot be delivered until the receiver is ready. Of course you could use event queues, but you'd have to protect them with mutexes. With a lot of components, there will be a lot of lock/unlock scenarios and it will slow things down. And the worst case scenario is when one component crashes during a lock.. Who's gonna unlock it? Designing a threaded architecture requires a lot of thought and skill. I'd say threading and multiprocessing should only be used when absolutely necessary. Bad use of both technologies will punish you later...
ActiveX development is shiteasy today. ATL makes it a breeze. In fact, when I do GUI stuff, I try to make most of my stuff ActiveX components so that I can reuse it later. And the good part is that the overhead of ActiveX components is very small. Sometimes it's even better than "ordinary" windows/window classes since you can make ax controls windowless.
They have been constantly upgrading the GNU tools, been busy putting together a new kernel with their tools (Mach + tools -> Hurd as per the GNU project mission statement), contributing with a desktop system/platform for the GNU operating system (GNUStep), updating emacs, the editor for the GNU operating system, as time passes by, and loads of other stuff. Take a look at GNU Projects and GNU Software too see what the GNU project has been doing for ther last decade. These projects are both directly and indirectly supported by the FSF in various ways (money, hardware or whatever they're donated).
What Linux distributions and other "projects" have been doing is using GNU stuff all along. Which is per definition ok. But I don't see why FSF and related GNU projects shouldn't be able to take some credit. It's not like their demanding money, advertising or anything. They want recognition for their work.
Some argues that MIT/X Consortium and Perl org should get equally as much recognition. The fact is that they do. The only reason why FSF wants it spelled GNU/Linux is because Linux would not run without GNU. The operating system would NOT be complete. You can run stuff without perl, you can run stuff without X, but you can't run stuff without linkers, loaders, and shells (at least not efficiently). Sure, rip out GNU stuff and put in BSD, but then it would be BSD/Linux.
If I was a BSD developer, and someone created an operating system by ripping out the GNU stuff and replacing it with BSD stuff, I'd be cranky too if someone called it "Linux". The voice of FSF in the Linux community should perhaps not always adhered to, but it should most definately be heard.
Gnome joined the GNU Project. The GNU project is lead by RMS. This is doesn't happen automatically by using the GPL. You have to do that actively. If you do that, then of course the project leader gets a piece of the action. I mean, it's Gnome which is a part of the GNU Project, not the other way around. If the Gnome people doesn't like this, they can bail out of the GNU Project.
Obviously the Gnome people saw a benefit in joining the GNU project. No one was forced to do it.
My point is that RMS/FSF/GNU has, under there own roof, produced negligable amounts of usefull code in the last decade.
Yes. It's your moot point. You have nothing to say about this. And I get pissed of every time people attack the FSF for no f*cking reason. Everything is done be free will. Let the Gnome people which actually DO something, decide whether FSF/GNU project is a good thing or not. You just have a problem with RMS (what I don't know, and I don't care).
I myself prefer BSD license before GPL, but I still respect the GPL, FSF and RMS. I don't have to stick a GPL on my code, I don't have to join the GNU project, and I don't have to give my copyright to the FSF. Know why? Because I'm free NOT do it, and RMS is not forcing me.
You didn't write the Linux kernel nor any GNU tool, so why are you whining? You're still using GNU stuff, aren't you? If you are so fed up with GNU, why don't you install FreeBSD instead? Either way, stop whining.
Who the hell was Alan Thicke anyway?
Notice the direction of the arrow? (Do you even know what the arrow means btw? Take a maths class..)
Microsoft put down a lot of money into their products. If they want money for it, and you want to use it, then pay up or shut up. If you don't pay for it, you cannot complain the slightest about their license.
You are however free not to choose Microsoft products. Then you certainly won't pay a dime to Gates. You're more likely to take away some profit from him.
I am not arguing what you believe is right. I agree with you that one should be able to buy the software and not a license to use it. I'd pay more for the software than the license. What I'm arguing is that you are not free to do this by law.
But you don't have to obey to these bloody licenses, there are much more software out there, that is not licensed this way. Anything licensed under BSD or GPL is a good start. Both allow you to do what you want with the software as long as you don't distribute it. The GPL denies certain things when distributing it (like NOT making the source freely available). BSD had an advertisment clause, but it is gone now, meaning you can do whatever you want with it. If this is the freedom you want, then go ahead and use this software instead.
For what its worth, you could print out the BSD kernel code, roll it and smoke it. No one is going to fine you for that! (unless you put something in the roll.. ;)
Not if you buy Microsoft software you don't. That's the point. You only buy a license to use it under their terms. What you say is irrelevant, you agreed to the EULA when you bought and installed the product. If you wan't to own the product, then don't buy Microsoft software.
And as for spying.. Are you out of your mind? Sure they could do that, but they could not use it in a court. Spying, or tapping, may ONLY be performed if a court order has been issued. Microsoft would get in serious trouble, probably more serious than this monopoly thing. Remember when Intel tried to push CPU identification numbers?
The gain of something is always measured against the risks and effort. In this case the risk is far too high as well as the effort.
I'm not pro-Microsoft, but sometimes these conspiracy theories are pretty lame. Perhaps you should think before you start shouting about things you KNOW NOTHING about?
RedHat has shipped bugs before, how come you're not stabbing them for their "Red Carpet" (or whatever they call it).
Yes it would be considered unsafe in C#.
One thing that has "bothered" me is the GTK bindings for Haskell. How the h*ll can one describe a GUI interface using nothing but expressions? I guess I'll have to do some investigations one of these days.. :)
I agree with you that C# is probably better for the "ordinary programmer". It's turing complete, it has a rich class library (pretty much like java), and it has the "smooth" C syntax ;) Haskell on the other hand is very extreme in nature and requires some extreme thinking of an "ordinary programmer" since the ideas behind the Haskell language is fundamentally different from those behind C#. And I guess the same applies for a person who comes from a functional background that uses C# (or C, C++ and the like).
First of all, the compiler cannot make "intelligent" decisions about how you want the object to be used. The reason is basically because of side effects. Programming using side effects is basically the same thing as programming by maintaining state. Since we're maintaining states, the order of events (statements=memory access) is significant. (Think about it.. you cannot go to work before you have woken up :)
Same thing here. Memory access related stuff is *very* hard to optimize the way you describe. You'd have to find every corner case and you'd have to analyze the code thouroughly during compilation - a sort of runtime analysis. In this simple example, a compiler could easily trap it (some do warn). But there are more hard to spot errors which compilers cannot easily trap.
Anyhow, it is easier to specify simple rules which the programmer must adhere to, instead of making the compiler extremely complex. (Chances are that complex compilers produce more errors than you.) If you break the rules, it's your problem.
C# on the other hand manages memory accesses for you. In fact you never get to touch raw memory, unless you explicitly say so (and that memory will not be in the same "environment" as your managed memory). It can do garbage collections, memory compacting, dead data removal and all sorts of things, which is very hard (if not impossible) without an extensive runtime.
[OT Warning]: Speaking of memory managed languages, Haskell is a language that hides basically all memory from you. It is purely functional, thus there is no such thing as "state". For a non-functional programmer, writing an application in terms of equations, expressions and pattern match rules can be... hm... an experience? Anyhow, since you do not have anything called state, the runtime can mix and match any evaluation as it is needed.
It can
IIRC this act is based on the EU privacy directives. The goal is that all EU members shall implement a "compatible" act. In Sweden, these laws has already been implemented (some know them as PUL). Hopefully all EU members have implemented this real soon now.
That statement is basically the same as "Everybody is guilty, until proven innocent". I have not proved to anyone that I'm not a terrorist, so according to your view of things, I'm probably planning a massive attack against thousands of innocent lives.
Think before you call me a terrorist, you carnivorous monster.
Have you even compared any BSD against a Linux distribution, or are just another clueless script kiddie that just cannot get the scripts to work in a BSD environment?
I've been hired by companies which are typically closed source companies, but still have used GPL'd stuff inhouse for development. And most of the time, the inhouse developers are good persons, and distribute the changes back to the community, eventhough they are not obligated. Pretty much BSD spirit.
Yes, but host byte ordering is of no relevance with respect to this...? I think you should copy'n'paste the whole context before replying ;P