I am assuming you are talking about the server here, but you are incorrect; Windows 2000 Terminal Services definitely does support remote drive access and sound to clients.
Local and state governments have deadlines just like in the private sector. The only real difference is that we have to deal with a lot more buricratic cr*p. If any of my projects were 7 years over due, I would expect to get canned, or demoted.
Yes, but none of your projects are giant agency-defining cash sinks. The smaller projects, the details of the organization, they get done. The large, sweeping stuff doesn't; and yes I'm saying that from personal experience.
Windows XP and higher support Remote Drive Sharing and Remote Sound over a regular Remote Desktop connection. Windows 2000 and below support Remote Desktop (well, the same protocol, but it's Terminal Services), but don't support the drive sharing or sound forwarding.
After all, to challenge this, MS would have to acknowledge the widely-used "Windoze" mispeling of their trademark name.
No they wouldn't. A synonym, despite any spelling differences, could still be argued as being confusingly similar. In fact, if they tried that, they'd probably end up in contempt of court (or whatever the appropriate localized version of that is) in the countries where they were ordered to stop using the Lindows name.
Re:Good... down with Real
on
Real Problems
·
· Score: 2, Interesting
They got the message on the download, anyway. I can get an.exe for the free version only two clicks from the front page.
They got the message on being an annoying and intrusive player too. RealPlayer 10, even the free version, has no ad popups, doesn't sit in your system tray, and spyware detectors say it's clean. From my initial glance over the preferences, all the "phone home" options are off by default too.
I had to download it because of trouble I was having with Real Alternative and streaming settings; and I was very pleasantly surprised. There's no real reason to avoid having to install it anymore.
Kinda hard to do so... From the SourceForge page linked above:
This Project Has Not Released Any Files
Isn't the number one rule of releasing an OS project to actually have something to release first? Sure MS prob hasn't "gotten around to it" but it seems to me they're getting "OSS cred" without even making a release OSS yet...
On the contrary, it sounds like Microsoft is fitting in perfectly with your average Sourceforge project! (FWIW, there's a release up now.)
For me, the enqueue function makes it well worth it.
You could enqueue with Winamp 2.x.
Re:From sSomeone who pitches those PHB's...
on
Why PHBs Fear Linux
·
· Score: 1
I have to disagree with you there...from what I've seen there are definately more Linux zealots roaming around, and they are making Linux look very bad.
This is exactly right, and was the biggest hurdle I had to overcome in getting the bosses at my company to finally commit to a Linux path. They're not tech idiots, but they're not gurus either -- they knew about Linux just enough to correlate it with the type of people who mostly seemed to be 15 year olds who spell Microsoft with a $ instead of an S. They saw Linux not as a viable operating system, but a toy used by people who are just raging against the machine.
I don't want to say exactly, since we were a SCO partner in the past and it seems like that's the best way to get sued by them, but I will say that we're one of the companies listed under the Linux section of this post, which has a copy and paste of the summaries of their case studies from their website.
I actually went and checked SCO's website to see if I could find the page of their Linux case studies there, but it seems like they've removed them all within the past month or so.
If you're responsible for the machines you run how can you abdicate that responsibility by using whatever some package maintainer decides to give you?
One would assume that the folks at RedHat, since it's their full time job, know more about the details of what's the best way to set up a package than someone who's new to a particular package and looking to roll it out across several machines -- especially since they support it and are privy to knowledge of problems with their configuration across multiple hardware environments.
Speaking of RedHat doing something weird... RedHat managed to _rename_ p_pptr to parent in task_struct in the kernel. How did they manage to get away with something like that?
Likely because RedHat's kernels aren't stock kernels, they include many different patches, like NPTL and the backported O(1) scheduler; that makes them behave quite different than other kernels.
Changing an identifier name is a simple way of making sure that nobody's going to blindly install something that might break part of the changed internals. Since they're going to have to track down the identifier problem, they'll be forced to look into the code to find the other differences. And in the event that the identifier is all that needs to be changed, a simple sed(1) and you're done.
Of course, then the pendulum has gone too far in the other direction. Let's say I have a beef with some company that I believe manufacture's a faulty product. If the company wishes to nip in the bud a series of class action suits, they may just outspend me. I get stuck with a bill for the millions they spent on defense if I lose... This isn't how the legal system here is supposed to work.
Then make the rule "loser pays to the winner either the winner's court costs or the amount that they'd spent on their own lawyer, whichever is less."
ev1servers.net features as one of Microsoft's case studies.
Oh FFS, my own company is featured as a case study on SCO's website (from several years ago when we were rolling out Caldera OpenLinux in a big way), but that doesn't mean we're beholden to SCO at all, quite the contrary in fact since we're rolling everything over to an in-house distro based off of Red Hat.
Microsoft most likely featured EV1 because EV1 is the biggest hosting provider offering Windows servers.
FYI, thinking is something you do inside your head. Talking, on the other hand, is an action that can have consequences in the world. It's unfortunate that the urge to accept responsibility for the consequences of one's actions is not quite as intrinsic as the urge to run one's mouth.
Talking is distributed thinking. As soon as you start looking down upon talking about abuse, you at the same time prevent anyone from doing anything to stop it.
You should probably check out the new DynamicMethod class: it allows creating methods at runtime that are not bound to a dynamic assembly and whose code can be garbage collected once it's no longer in use. Mono implements it already.
Awesome. That's exactly what I need; and Mono implementing it is even better since that's my development platform.
Instead you would more then likely have those scripts compiled and objects "loaded" on the fly using ICodeCompiler using the GenerateInMemory property set to true. You can then recompile this on the fly at any point.
That's the approach I was planning on using, however that just creates a more-or-less standard assembly in memory. There's no way to unload the assembly. Recompiling doesn't unload the old assembly, just returns you a reference to the new assembly via the CompiledAssembly property. The example you gave about recompiling Script A while Script B is instantiated isn't even an issue, since Script B doesn't overwrite Script A -- it co-exists with it in memory.
In an application it's expected that user supplied code can and will be changed and recompiled often; you'll quickly run out of memory as all those old and no-longer-needed assemblies start to add up.
Suzanne Cook, a developer of the CLR Loader, wrote up this blog entry on why unloading assemblies isn't supported in.NET, and pretty much any time it's brought up, Microsoft's response is basically "can't do it in our architecture, if cross-AppDomain calls are too slow, we'll work to speed them up" but they completely miss the constraint of not being able to pass parameters that you can't serialize across AppDomains.
Of course.NET already has support for JScript and VBScript -- however, the main problem with scripting on.NET is that once you load code into memory, there's no way to unload it without having to destroy the entire AppDomain.
This leads to problems where you've got an environment where you'll be running lots of dynamic script code -- your process pretty much leaks memory. The only solution is to run your scripted code off in another AppDomain, but then you've got the considerable overhead of doing cross-AppDomain calls (serialization/deserialization, both ways) and you're restricted to types that can be passed across the AppDomain barrier.
Even then, you've got to be extremely careful because if you pass back a type that was defined in the assembly generated by the script, your primary AppDomain will silently load the assembly itself to deal with the type (and keep it open forever -- the thing we wanted to avoid!).
I understand there are considerable performance gains in.NET because of the no-unloading-assemblies behavior; but it makes.NET unusuable in the class of applications where you're running lots of different code from different sources; in this case, a MUD where users can script their own objects -- with the ability to arbitrarily rewrite and change their scripts at any time..NET seems like it has wonderful support for everything else needed (Code Access Security, etc.), but that one single sticking point is a dealbreaker.
I'm not all that familiar with this aspect of Java -- does Java suffer from the same problem of not being able to unload code/types from memory?
Even if you do manage to get all of the systems designed and get ready to roll the upgrades out, someone will just come along and axe the plan while they try to figure out if this move will make them risk their neck in the slightest. Trying to work for people who essentially can't be fired is a nightmare.
The above is absolutely true, and during some contracting work with the military, I was even told pretty much exactly what's said above.
When it comes to Government IT, the only thing that can really get you fired is if you opened a new security vulnerability. The way the admins deal with that is by not allowing any changes to occur under their watch. It's extremely infuriating.
So wrap a "using" statement around the block and don't worry about it. You're guaranteed that the object will release all its unmanaged resources (like socket handles) when the block terminates, no matter how it terminates. You don't have to worry about the details. It pretty much takes care of the problem of C++'s stack local variables... and you can call the IDisposable.Dispose() method in the instance where you're using them more similar to a new/delete C++ heap variable.
Why can't a VM support multiple inheritence? Any pointers?
The CLR actually supports multiple inheritance, but if you use it you lose CLS compliance. Multiple inheritance really shouldn't need to happen in an environment where you've got interfaces and delegation anyhow.
Re:A Wonderful Innovation for the Culinary Industr
on
Reanimated Lobsters?
·
· Score: 1
Well, as far as practical uses go (with the lobster) this could revolutionize the cooking industry! Imagine being able to have live lobsters available at an instant's notice!
The fact that they don't tend to live very long after being unfrozen indicates that they're not nearly "as good as fresh".
The real problem is not so much that the Yukon date has slipped, it's that Whidbey (The next version of Visual Studio.NET and the.NET framework) is slipping with it. For who knows what reason, Microsoft decided that these products must be released together.
The reason they must ship together is because SQL Server is the guinea pig for Whidbey's new hosting interfaces (running an instance of the Framework inside your own non-managed application). This is not a trivial addition to the.NET Framework.
Check out this.NET architect's blog posting going briefly into some of the details of hosting and why SQL Server is so important to Whidbey.
And Microsoft.com runs on IIS -- but that doesn't mean that IIS is everything to everyone; nor does the fact that Slashdot runs on MySQL mean that MySQL is good for everyone.
MySQL is really good at a really limited subset of queries. If MySQL is all you know, then your ignorance is bliss in that you don't know all the other wonderful things a real RDBMS can do for you since MySQL never offered them to you.
Once you've used a real database system, you could never go back to the chains of MySQL.
Slashdot Mirror
I am assuming you are talking about the server here, but you are incorrect; Windows 2000 Terminal Services definitely does support remote drive access and sound to clients.
I stand corrected.
Local and state governments have deadlines just like in the private sector. The only real difference is that we have to deal with a lot more buricratic cr*p. If any of my projects were 7 years over due, I would expect to get canned, or demoted.
Yes, but none of your projects are giant agency-defining cash sinks. The smaller projects, the details of the organization, they get done. The large, sweeping stuff doesn't; and yes I'm saying that from personal experience.
Windows XP and higher support Remote Drive Sharing and Remote Sound over a regular Remote Desktop connection. Windows 2000 and below support Remote Desktop (well, the same protocol, but it's Terminal Services), but don't support the drive sharing or sound forwarding.
After all, to challenge this, MS would have to acknowledge the widely-used "Windoze" mispeling of their trademark name.
No they wouldn't. A synonym, despite any spelling differences, could still be argued as being confusingly similar. In fact, if they tried that, they'd probably end up in contempt of court (or whatever the appropriate localized version of that is) in the countries where they were ordered to stop using the Lindows name.
They got the message on the download, anyway. I can get an .exe for the free version only two clicks from the front page.
They got the message on being an annoying and intrusive player too. RealPlayer 10, even the free version, has no ad popups, doesn't sit in your system tray, and spyware detectors say it's clean. From my initial glance over the preferences, all the "phone home" options are off by default too.
I had to download it because of trouble I was having with Real Alternative and streaming settings; and I was very pleasantly surprised. There's no real reason to avoid having to install it anymore.
which AFAIK is hard on linux as there's no non-blocking file IO.
There certainly is a fully-featured asynchronous IO API in Linux 2.6.
Kinda hard to do so... From the SourceForge page linked above:
This Project Has Not Released Any Files
Isn't the number one rule of releasing an OS project to actually have something to release first? Sure MS prob hasn't "gotten around to it" but it seems to me they're getting "OSS cred" without even making a release OSS yet...
On the contrary, it sounds like Microsoft is fitting in perfectly with your average Sourceforge project! (FWIW, there's a release up now.)
For me, the enqueue function makes it well worth it.
You could enqueue with Winamp 2.x.
I have to disagree with you there...from what I've seen there are definately more Linux zealots roaming around, and they are making Linux look very bad.
This is exactly right, and was the biggest hurdle I had to overcome in getting the bosses at my company to finally commit to a Linux path. They're not tech idiots, but they're not gurus either -- they knew about Linux just enough to correlate it with the type of people who mostly seemed to be 15 year olds who spell Microsoft with a $ instead of an S. They saw Linux not as a viable operating system, but a toy used by people who are just raging against the machine.
What company is it, prey tell?
I don't want to say exactly, since we were a SCO partner in the past and it seems like that's the best way to get sued by them, but I will say that we're one of the companies listed under the Linux section of this post, which has a copy and paste of the summaries of their case studies from their website.
I actually went and checked SCO's website to see if I could find the page of their Linux case studies there, but it seems like they've removed them all within the past month or so.
If you're responsible for the machines you run how can you abdicate that responsibility by using whatever some package maintainer decides to give you?
One would assume that the folks at RedHat, since it's their full time job, know more about the details of what's the best way to set up a package than someone who's new to a particular package and looking to roll it out across several machines -- especially since they support it and are privy to knowledge of problems with their configuration across multiple hardware environments.
Speaking of RedHat doing something weird... RedHat managed to _rename_ p_pptr to parent in task_struct in the kernel. How did they manage to get away with something like that?
Likely because RedHat's kernels aren't stock kernels, they include many different patches, like NPTL and the backported O(1) scheduler; that makes them behave quite different than other kernels.
Changing an identifier name is a simple way of making sure that nobody's going to blindly install something that might break part of the changed internals. Since they're going to have to track down the identifier problem, they'll be forced to look into the code to find the other differences. And in the event that the identifier is all that needs to be changed, a simple sed(1) and you're done.
Of course, then the pendulum has gone too far in the other direction. Let's say I have a beef with some company that I believe manufacture's a faulty product. If the company wishes to nip in the bud a series of class action suits, they may just outspend me. I get stuck with a bill for the millions they spent on defense if I lose... This isn't how the legal system here is supposed to work.
Then make the rule "loser pays to the winner either the winner's court costs or the amount that they'd spent on their own lawyer, whichever is less."
ev1servers.net features as one of Microsoft's case studies.
Oh FFS, my own company is featured as a case study on SCO's website (from several years ago when we were rolling out Caldera OpenLinux in a big way), but that doesn't mean we're beholden to SCO at all, quite the contrary in fact since we're rolling everything over to an in-house distro based off of Red Hat.
Microsoft most likely featured EV1 because EV1 is the biggest hosting provider offering Windows servers.
Perhapse adding the DNS group as an optional component to URLS such asc omputers.geek"
k !opennic
"http://ICANN`slashdot.org"
"http://OpenNIC`
Why break the heirarchial format of domains?
http://slashdot.org!icann
http://computers.gee
FYI, thinking is something you do inside your head. Talking, on the other hand, is an action that can have consequences in the world. It's unfortunate that the urge to accept responsibility for the consequences of one's actions is not quite as intrinsic as the urge to run one's mouth.
Talking is distributed thinking. As soon as you start looking down upon talking about abuse, you at the same time prevent anyone from doing anything to stop it.
It didn't help their case that it was Windows-based (get a virus/worm, lose communications *:^).
:p)
So that's why communications were always going down whenever there was trouble on the Enterprise!!! (...in the enterprise?
You should probably check out the new DynamicMethod class: it allows creating methods at runtime that are not bound to a dynamic assembly and whose code can be garbage collected once it's no longer in use.
Mono implements it already.
Awesome. That's exactly what I need; and Mono implementing it is even better since that's my development platform.
Instead you would more then likely have those scripts compiled and objects "loaded" on the fly using ICodeCompiler using the GenerateInMemory property set to true. You can then recompile this on the fly at any point.
.NET, and pretty much any time it's brought up, Microsoft's response is basically "can't do it in our architecture, if cross-AppDomain calls are too slow, we'll work to speed them up" but they completely miss the constraint of not being able to pass parameters that you can't serialize across AppDomains.
That's the approach I was planning on using, however that just creates a more-or-less standard assembly in memory. There's no way to unload the assembly. Recompiling doesn't unload the old assembly, just returns you a reference to the new assembly via the CompiledAssembly property. The example you gave about recompiling Script A while Script B is instantiated isn't even an issue, since Script B doesn't overwrite Script A -- it co-exists with it in memory.
In an application it's expected that user supplied code can and will be changed and recompiled often; you'll quickly run out of memory as all those old and no-longer-needed assemblies start to add up.
Suzanne Cook, a developer of the CLR Loader, wrote up this blog entry on why unloading assemblies isn't supported in
Of course .NET already has support for JScript and VBScript -- however, the main problem with scripting on .NET is that once you load code into memory, there's no way to unload it without having to destroy the entire AppDomain.
.NET because of the no-unloading-assemblies behavior; but it makes .NET unusuable in the class of applications where you're running lots of different code from different sources; in this case, a MUD where users can script their own objects -- with the ability to arbitrarily rewrite and change their scripts at any time. .NET seems like it has wonderful support for everything else needed (Code Access Security, etc.), but that one single sticking point is a dealbreaker.
This leads to problems where you've got an environment where you'll be running lots of dynamic script code -- your process pretty much leaks memory. The only solution is to run your scripted code off in another AppDomain, but then you've got the considerable overhead of doing cross-AppDomain calls (serialization/deserialization, both ways) and you're restricted to types that can be passed across the AppDomain barrier.
Even then, you've got to be extremely careful because if you pass back a type that was defined in the assembly generated by the script, your primary AppDomain will silently load the assembly itself to deal with the type (and keep it open forever -- the thing we wanted to avoid!).
I understand there are considerable performance gains in
I'm not all that familiar with this aspect of Java -- does Java suffer from the same problem of not being able to unload code/types from memory?
Even if you do manage to get all of the systems designed and get ready to roll the upgrades out, someone will just come along and axe the plan while they try to figure out if this move will make them risk their neck in the slightest. Trying to work for people who essentially can't be fired is a nightmare.
The above is absolutely true, and during some contracting work with the military, I was even told pretty much exactly what's said above.
When it comes to Government IT, the only thing that can really get you fired is if you opened a new security vulnerability. The way the admins deal with that is by not allowing any changes to occur under their watch. It's extremely infuriating.
finally or with just don't cut it.
... and you can call the IDisposable.Dispose() method in the instance where you're using them more similar to a new/delete C++ heap variable.
So wrap a "using" statement around the block and don't worry about it. You're guaranteed that the object will release all its unmanaged resources (like socket handles) when the block terminates, no matter how it terminates. You don't have to worry about the details. It pretty much takes care of the problem of C++'s stack local variables
Why can't a VM support multiple inheritence? Any pointers?
The CLR actually supports multiple inheritance, but if you use it you lose CLS compliance. Multiple inheritance really shouldn't need to happen in an environment where you've got interfaces and delegation anyhow.
Well, as far as practical uses go (with the lobster) this could revolutionize the cooking industry! Imagine being able to have live lobsters available at an instant's notice!
The fact that they don't tend to live very long after being unfrozen indicates that they're not nearly "as good as fresh".
The real problem is not so much that the Yukon date has slipped, it's that Whidbey (The next version of Visual Studio.NET and the .NET framework) is slipping with it. For who knows what reason, Microsoft decided that these products must be released together.
.NET Framework.
.NET architect's blog posting going briefly into some of the details of hosting and why SQL Server is so important to Whidbey.
The reason they must ship together is because SQL Server is the guinea pig for Whidbey's new hosting interfaces (running an instance of the Framework inside your own non-managed application). This is not a trivial addition to the
Check out this
Isn't Slashdot run on MySQL?
And Microsoft.com runs on IIS -- but that doesn't mean that IIS is everything to everyone; nor does the fact that Slashdot runs on MySQL mean that MySQL is good for everyone.
MySQL is really good at a really limited subset of queries. If MySQL is all you know, then your ignorance is bliss in that you don't know all the other wonderful things a real RDBMS can do for you since MySQL never offered them to you.
Once you've used a real database system, you could never go back to the chains of MySQL.