Or you can roll your own. The only problem is that the cert is signed by you, so your customer's browser can't be certain that you are who you say you are, and will therefore issue a warning to the user.
For installing a cert on a Windows IIS server: Find a recent copy of the makecert tool. makecert -r -pe -n "CN=www.yourserver.com" -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 Then use the IIS management tool to "assign an existing certificate" to the site. The certificate created before should show up as available.
For installing a cert on Apache: ssleay req -out certificate.pem -nodes -new -x509 -days 2000 Now you have a pair of certificate files you can put in whatever directory your Apache install expects them to be in.
Yeah, it is a loss. RAII still works since all major implementations allow for a finalizer to run at GC time, but since GC isn't deterministic, the finalizer might not be run when you expect.
But this is kind-of looking a gift horse in the mouth. GC eliminated the need to explicitly dispose, so now you're complaining that you don't get the benefits of explicitly disposing. At least for heap-based allocations.
For stack-based variables, this is still a loss, but at least it is easy to fix. C# has a "using" construct that calls the Dispose() method when you exit the using block. If that doesn't work, a try-finally block will. But yeah, it would be nice if there were a way to declare automatic (in the C sense) objects in GC languages.
Hopefully, a standard will come of this, allowing (requiring?) manufacturers to indicate on the label some kind of expected lifespan for the media. That would be nice.
Safer to say "some kinds of GC operate well only when no more than 50%..." There are lots of different Garbage Collectors, with lots of different characteristics. Some have that problem, others don't.
Well, you have a point. Certain assemblies will be marked as trusted and will be marked as "callable from untrusted code" (i.e. there's no way you can hurt the system through the interfaces provided).
That's the same as Java's model, though. Certain classes are available from within the sandbox, and if those classes have security holes, they can be exploited..NET works the same way.
The question is where you draw the line between "providing APIs to untrusted code so the applets can do interesting stuff" and "protecting the user from applets that find holes in the APIs." ActiveX is probably too far to the left. Java is probably too far to the right. Where's.NET? Only time will tell...
To me this puts the security decisions up a level.
No, it doesn't. User code in the.NET VM has to have permission from the VM to operate "unsafely". If the VM can't verify the code and the code doesn't have permission to operate unsafely, the VM will refuse to run it. The security decision stays in the same place.
His point is essentially that.NET does not protect the user against untrusted code, while Java does. If you run.NET code, you have to trust the developer, because the system won't protect you against a malicious or careless developer. If you run Java code in a sandbox, you're safe, because the system will watch what's going on and can be sure of the safety of its information.
If that is the point, he's dead wrong.
Just like you can run Java code in or out of the sandbox, you can run.NET code in or out of the sandbox. If the developer does pointer arithmetic or anything else that cannot be verified as "safe", the code will require additional permissions to run. Just like calling the file system APIs requires additional permissions in Java. It just means that if you want to write in C and target.NET, you can, but your users will have to grant your code additional permissions before it will run.
Ummm... are you saying if a developer chooses to write unsafe code on.NET it is the fault of the developer that he can do so? By it's very name it implies that remote computers are going to connect to it, so one would hope it's not built to be too riddled with security holes or potential to be 'dangerous'.
The developer can choose to do whatever he/she wants. The nice thing about.NET is that the end user can then choose whether or not to allow that developer's code to run on his/her machine, and can obtain additional information that aids him/her in making that decision.
The.NET VM will verify the bytecode to determine whether the developer has done anything "unsafe" (such as perform pointer arithmetic or call native Windows code). If so, the VM will check the user's security settings to determine whether unsafe code is allowed to run in this context.
You can choose what privileges are granted to a.NET app. If the.NET app uses unverifiable code, then it requires the "run unverifiable code" privilege. You'd be insane to grant that privilege to.NET applets from unknown web sites, just like you'd be insane to grant JNI access to Java applets from unknown web sites.
Actually, it is more than that..NET can run WITH or WITHOUT the sandbox. If you're running web applets, you'll be running WITH the sandbox, and all is good. In that case, the C or C++ or IL Assembly simply won't run if it isn't verifiably safe.
Free and malloc are NOT very simple algorithms. They have arbitrary complexity. malloc ranges from the normal case of about 100 instructions (when a block of memory of the correct size is available) to unbounded (when data must be paged out to make enough room for the new allocation and the data for tracking it). Free can also be arbitrarily slow, as releasing one block may trigger a coalesce operation.
So you have to measure time per malloc and time per free, then total them up and compare it to GC's time per allocation and time spent in GC. In some cases, one will be significantly larger than the other, but in most nontrivial programs, using modern malloc/free and modern GC, it comes out pretty close to even.
Some argue that the "pause" from GC is a problem. Maybe. Except that as mentioned before, malloc can also "pause" for arbitrarily long times. And a lot of work has been done on "concurrent" GC that doesn't pause. If you can afford paging in from disk (swap file), you can also afford GC's "pause".
Finally, when you write a big program, you spend incredible effort in your program tracking memory. That takes cycles. "If x then save a copy cause we'll have to free it later, etc."
The bottom line is that there are some cases where GC still won't work, but those cases are getting smaller and smaller. For most cases, the argument that GC is slow or inefficient just isn't true. Go do some real benchmarks, or go study up on the already published benchmarks. GC is pretty efficient, and malloc/free has no significant speed advantage anymore.
Two guys were hiking in the forest. Suddenly, they realized that they had walked between a mother bear and her cubs. Immediately, one of the guys kicked off his big hiking boots, pulled his running shoes out of his pack, and started lacing them up.
The other guy said, "you can't outrun the bear, even in running shoes!"
The first guy replied, "I don't have to outrun the bear. I just have to outrun you."
Moral: While a dedicated hacker who really wants to get into your particular site won't be stopped by changing ports, that is rare. More commonly, you just have to stop worms and script kiddies, and generally they just portscan for servers with the "normal" port open.
Even better if you don't want a 2 year comittment, the slightly-outdated Mpx200 is available for cheap, even without long contracts. I have one in my pocket now, and I've written a few little programs for it. Works great.
The standard version runs Smartphone 2002, so you can download eVC 3.0 and the SP 2002 SDK and start hacking.
Some editions of this phone also have Java support. But not all. So if you expect to program in Java, double-check before buying.
If you can find one that has been upgraded to Smartphone 2003 (i.e. hacked, since there never was an official release of this OS), you can program using.NET Compact Framework and/or eVC 4.0.
Faster compile of the full product. You only invoke the compiler process once, and much less work for the linker to do.
Much better optimization. Compilers can only optimize within a compilation unit. Intel and Microsoft have "Link-time code generation" compilers which performs a final optimization pass during link, but if you aren't using those compilers, there might be a significant amount of additional optimization enabled by putting everything in the same compilation unit.
Disadvantages:
You're not doing it the way everyone expects you to do it. Certain components (the compiler, the linker, and pre-existing code) might have been designed under the assumption that individual files would be compiled separately. The pre-existing code might have declared static (per-file) variables or functions in a way that could collide with other code (namespaces might help here). The compiler and linker might have limits. And you might not hit those limits until late in the project.
For building the whole product, yeah, it will be faster. But for making a small change and rebuilding the results of that change, it might be much slower.
As with every issue you'll ever run into, there are two (or three) sides to it.
Shared cache maybe? 2 processors efficiently sharing a 2 MB cache will probably work better than 2 processors with independent 1 MB caches in most cases.
Not that brain dead. I have 4 disks hooked up to my IDE ports, and running all 4 at top speed only uses up 20% of the CPU. SCSI would certainly be better, but IDE isn't quite as bad as you're making it out to be.
Strangely, one of the best (IMHO) "lightweight" languages isn't even mentioned (as far as I can tell, anyway). Lua is really lightweight (easy to learn, and very easy on resource usage) yet very powerful. I wonder why it doesn't get more attention...
The point was that swapping doesn't have much of a CPU hit, and the latency for swapping is smaller than the latency for loading and filtering.
Pulling in 10 MB of textures from swap and getting them onto the video card takes less than one second of latency and almost 0 CPU.
Pulling 10 MB (decompressed size) of textures from the level files, decompressing them, filtering them for the installed graphics card and settings, and getting them onto the video card can take 5-10 seconds of 100% CPU usage.
Guess which one is going to cause more stuttering?
Textures can be in one of 3 "places": 1. In the HalfLife level files, compressed and raw. 2. In system memory, properly formatted for direct transfer to the video card. 3. In video card memory.
Going from stage 1 to stage 2 takes some CPU power as well as disk access. Going from 2 to 3 is probably a lot easier on the system, even if the system memory has been paged out (just page back in, no significant CPU cycles used, just a bit of latency).
If properly done, you can do some of the stage-1 to stage-2 work while the game is playing, but it is a real balancing act between keeping frame rates up during play and keeping load times down between levels. If the balance is off just a bit, the work isn't done by the time the texture is needed, and the game stuttttters.
More often than not, correlation means two things are caused by the same factors, not that one causes the other.
In this case, which counties switched to touch-screen voting? Why? Could the factors that led them to switch (population density, demographics) have also been factors that led the voters to swing similarly?
Fast drives can sustain about 60 MB/s nowadays, so don't put more than (max channel rate)/(max drive rate) = (320)/(60) = around 5 drives on a single channel.
As for multiple controllers, if they aren't present for redundancy purposes, you're probably just as well off using just one.
But then again, I'm just a Slashdotter who hasn't kept up with the latest specs, so I'm pretty much just making stuff up. Free advice is worth every penny.
Slashdot Mirror
Or you can roll your own. The only problem is that the cert is signed by you, so your customer's browser can't be certain that you are who you say you are, and will therefore issue a warning to the user.
For installing a cert on a Windows IIS server:
Find a recent copy of the makecert tool.
makecert -r -pe -n "CN=www.yourserver.com" -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12
Then use the IIS management tool to "assign an existing certificate" to the site. The certificate created before should show up as available.
For installing a cert on Apache:
ssleay req -out certificate.pem -nodes -new -x509 -days 2000
Now you have a pair of certificate files you can put in whatever directory your Apache install expects them to be in.
Yeah, it is a loss. RAII still works since all major implementations allow for a finalizer to run at GC time, but since GC isn't deterministic, the finalizer might not be run when you expect.
But this is kind-of looking a gift horse in the mouth. GC eliminated the need to explicitly dispose, so now you're complaining that you don't get the benefits of explicitly disposing. At least for heap-based allocations.
For stack-based variables, this is still a loss, but at least it is easy to fix. C# has a "using" construct that calls the Dispose() method when you exit the using block. If that doesn't work, a try-finally block will. But yeah, it would be nice if there were a way to declare automatic (in the C sense) objects in GC languages.
Hint: Look up what NIST stands for.
Hopefully, a standard will come of this, allowing (requiring?) manufacturers to indicate on the label some kind of expected lifespan for the media. That would be nice.
Yay!! I've found intelligent life on Slashdot!
Safer to say "some kinds of GC operate well only when no more than 50%..." There are lots of different Garbage Collectors, with lots of different characteristics. Some have that problem, others don't.
Well, you have a point. Certain assemblies will be marked as trusted and will be marked as "callable from untrusted code" (i.e. there's no way you can hurt the system through the interfaces provided).
.NET works the same way.
.NET? Only time will tell...
That's the same as Java's model, though. Certain classes are available from within the sandbox, and if those classes have security holes, they can be exploited.
The question is where you draw the line between "providing APIs to untrusted code so the applets can do interesting stuff" and "protecting the user from applets that find holes in the APIs." ActiveX is probably too far to the left. Java is probably too far to the right. Where's
To me this puts the security decisions up a level.
.NET VM has to have permission from the VM to operate "unsafely". If the VM can't verify the code and the code doesn't have permission to operate unsafely, the VM will refuse to run it. The security decision stays in the same place.
No, it doesn't. User code in the
His point is essentially that .NET does not protect the user against untrusted code, while Java does. If you run .NET code, you have to trust the developer, because the system won't protect you against a malicious or careless developer. If you run Java code in a sandbox, you're safe, because the system will watch what's going on and can be sure of the safety of its information.
.NET code in or out of the sandbox. If the developer does pointer arithmetic or anything else that cannot be verified as "safe", the code will require additional permissions to run. Just like calling the file system APIs requires additional permissions in Java. It just means that if you want to write in C and target .NET, you can, but your users will have to grant your code additional permissions before it will run.
If that is the point, he's dead wrong.
Just like you can run Java code in or out of the sandbox, you can run
Ummm ... are you saying if a developer chooses to write unsafe code on .NET it is the fault of the developer that he can do so? By it's very name it implies that remote computers are going to connect to it, so one would hope it's not built to be too riddled with security holes or potential to be 'dangerous'.
.NET is that the end user can then choose whether or not to allow that developer's code to run on his/her machine, and can obtain additional information that aids him/her in making that decision.
.NET VM will verify the bytecode to determine whether the developer has done anything "unsafe" (such as perform pointer arithmetic or call native Windows code). If so, the VM will check the user's security settings to determine whether unsafe code is allowed to run in this context.
The developer can choose to do whatever he/she wants. The nice thing about
The
And just to clarify, his argument is false.
.NET app. If the .NET app uses unverifiable code, then it requires the "run unverifiable code" privilege. You'd be insane to grant that privilege to .NET applets from unknown web sites, just like you'd be insane to grant JNI access to Java applets from unknown web sites.
You can choose what privileges are granted to a
Actually, it is more than that. .NET can run WITH or WITHOUT the sandbox. If you're running web applets, you'll be running WITH the sandbox, and all is good. In that case, the C or C++ or IL Assembly simply won't run if it isn't verifiably safe.
Free and malloc are NOT very simple algorithms. They have arbitrary complexity. malloc ranges from the normal case of about 100 instructions (when a block of memory of the correct size is available) to unbounded (when data must be paged out to make enough room for the new allocation and the data for tracking it). Free can also be arbitrarily slow, as releasing one block may trigger a coalesce operation.
So you have to measure time per malloc and time per free, then total them up and compare it to GC's time per allocation and time spent in GC. In some cases, one will be significantly larger than the other, but in most nontrivial programs, using modern malloc/free and modern GC, it comes out pretty close to even.
Some argue that the "pause" from GC is a problem. Maybe. Except that as mentioned before, malloc can also "pause" for arbitrarily long times. And a lot of work has been done on "concurrent" GC that doesn't pause. If you can afford paging in from disk (swap file), you can also afford GC's "pause".
Finally, when you write a big program, you spend incredible effort in your program tracking memory. That takes cycles. "If x then save a copy cause we'll have to free it later, etc."
The bottom line is that there are some cases where GC still won't work, but those cases are getting smaller and smaller. For most cases, the argument that GC is slow or inefficient just isn't true. Go do some real benchmarks, or go study up on the already published benchmarks. GC is pretty efficient, and malloc/free has no significant speed advantage anymore.
(Yes, this is on-topic.)
Two guys were hiking in the forest. Suddenly, they realized that they had walked between a mother bear and her cubs. Immediately, one of the guys kicked off his big hiking boots, pulled his running shoes out of his pack, and started lacing them up.
The other guy said, "you can't outrun the bear, even in running shoes!"
The first guy replied, "I don't have to outrun the bear. I just have to outrun you."
Moral: While a dedicated hacker who really wants to get into your particular site won't be stopped by changing ports, that is rare. More commonly, you just have to stop worms and script kiddies, and generally they just portscan for servers with the "normal" port open.
Even better if you don't want a 2 year comittment, the slightly-outdated Mpx200 is available for cheap, even without long contracts. I have one in my pocket now, and I've written a few little programs for it. Works great.
.NET Compact Framework and/or eVC 4.0.
The standard version runs Smartphone 2002, so you can download eVC 3.0 and the SP 2002 SDK and start hacking.
Some editions of this phone also have Java support. But not all. So if you expect to program in Java, double-check before buying.
If you can find one that has been upgraded to Smartphone 2003 (i.e. hacked, since there never was an official release of this OS), you can program using
- Disadvantages:
- You're not doing it the way everyone expects you to do it. Certain components (the compiler, the linker, and pre-existing code) might have been designed under the assumption that individual files would be compiled separately. The pre-existing code might have declared static (per-file) variables or functions in a way that could collide with other code (namespaces might help here). The compiler and linker might have limits. And you might not hit those limits until late in the project.
- For building the whole product, yeah, it will be faster. But for making a small change and rebuilding the results of that change, it might be much slower.
As with every issue you'll ever run into, there are two (or three) sides to it.Why would you want more cores in your apple? I usually just cut out the core and throw it away. Do you do something useful with your apple cores?
Maybe you could find some multi-core apples growing at the Springfield Power Plant. Worth a try, I suppose.
Shared cache maybe?
2 processors efficiently sharing a 2 MB cache will probably work better than 2 processors with independent 1 MB caches in most cases.
Not that brain dead. I have 4 disks hooked up to my IDE ports, and running all 4 at top speed only uses up 20% of the CPU. SCSI would certainly be better, but IDE isn't quite as bad as you're making it out to be.
Strangely, one of the best (IMHO) "lightweight" languages isn't even mentioned (as far as I can tell, anyway). Lua is really lightweight (easy to learn, and very easy on resource usage) yet very powerful. I wonder why it doesn't get more attention...
Are you some kind of insensitive clod or something? :)
The point was that swapping doesn't have much of a CPU hit, and the latency for swapping is smaller than the latency for loading and filtering.
Pulling in 10 MB of textures from swap and getting them onto the video card takes less than one second of latency and almost 0 CPU.
Pulling 10 MB (decompressed size) of textures from the level files, decompressing them, filtering them for the installed graphics card and settings, and getting them onto the video card can take 5-10 seconds of 100% CPU usage.
Guess which one is going to cause more stuttering?
Textures can be in one of 3 "places":
1. In the HalfLife level files, compressed and raw.
2. In system memory, properly formatted for direct transfer to the video card.
3. In video card memory.
Going from stage 1 to stage 2 takes some CPU power as well as disk access. Going from 2 to 3 is probably a lot easier on the system, even if the system memory has been paged out (just page back in, no significant CPU cycles used, just a bit of latency).
If properly done, you can do some of the stage-1 to stage-2 work while the game is playing, but it is a real balancing act between keeping frame rates up during play and keeping load times down between levels. If the balance is off just a bit, the work isn't done by the time the texture is needed, and the game stuttttters.
Correlation != Cause
More often than not, correlation means two things are caused by the same factors, not that one causes the other.
In this case, which counties switched to touch-screen voting? Why? Could the factors that led them to switch (population density, demographics) have also been factors that led the voters to swing similarly?
And to answer the question you actually ASKED...
Fast drives can sustain about 60 MB/s nowadays, so don't put more than (max channel rate)/(max drive rate) = (320)/(60) = around 5 drives on a single channel.
As for multiple controllers, if they aren't present for redundancy purposes, you're probably just as well off using just one.
But then again, I'm just a Slashdotter who hasn't kept up with the latest specs, so I'm pretty much just making stuff up. Free advice is worth every penny.
So go for more smaller drives over fewer faster drives for RAID-5.
I meant to say larger.