You are on DSL or Cable and do NOT have a firewall? Spend a few bucks and get one!
Spend money on one?! Dear oh dear..
Zonealarm (requires annoying popups asking you to buy), Agnitum (requires reg), Kerio (reverts to free features after 30 days), Comodo (totally free as it's an advert for Comodo other products)
I don't know about the US, but you want an ISP that is intelligent about bandwidth. It is finite, and providing everyone with unlimited bandwidth would bankrupt the ISP. So... you need one that ignores your usage on non-peak times, that gives you a fair chunk of allowable bandwidth, and one that is upfront about its policies.
I use plusnet (in the UK), I have really unlimited usage between midnight and 4pm, 30Gb the rest of the time. They are open about their policies and have 'been in contact' with users that have used the network at full capacity 24/7. Apparently less than 1% of users use a noticeable amount of bandwidth, for these, Plusnet say: Of course, for the vast majority of people who don't use up to the usage allowance every month, a shared design like this doesn't pose any problems at all. However, the nature of any product designed in this way is that there will always be a number of customers who end up with an unsustainable long term usage pattern. This may be deliberate in some cases, but more often than not it is because after choosing a product, a customer's usage habits subsequently change. For these customers there are effectively three choices:
1. Upgrade to a different PlusNet product that is more suited to the new usage requirements.
2. Moderate peak time usage, either by reducing the amount of large downloads, or by scheduling more downloads to overnight periods when demand for interactive traffic is lower.
3. Find another ISP which is more suited to the specific usage requirements of that customer.
Plusnet did send out warning letters to a few users (adslguide has a report on it here. It should be noted that this was 2 years ago when everyone was on 0.5Mbps lines.
So anyway, for you - if you have a shortlist, ask them about traffic shaping and capacity management.
insulation - not for anything that might touch it, but insulated from the effects of the weather. I'm sure a bare-metal wire would get quite hot in the direct sunlight, and quite cold in the night at those altitudes. I think a tough plastic coating would increase its lifespan.
Yes, I remember them too - Larry Niven used to write about them, the power would be beamed down to a base station via microwaves. You'd need to fence a large area off to prvent people straying into it and being cooked (but as he said, put up a large fence with signs on it saying "cross this fence and you will die", anyone crossing the fence gets what they deserve and the Darwin awards get a new story). Of course, in the Us, you'd probably get sued for the first fataility.
I'd also say that the energy cost of raising a 10km insulated power cable into the air would also need to be resolved too. I'd think that 10km length of power cable would weigh quite a bit, not to mention how much resistance there would be in it that would affect the power output at ground level.
Yes, but what would Joe Schmoe do? Take the machine back tot he shop, or phone their customer support and be told that the driver needed to be upgraded, with instructions on how to do it. Its still pretty crap, but this is what Joe is used to with consumer technology nowadays.
They are a little bit old by my standards, let alone by 'computer time', so you do have to expect things will start to break. I recommend DosBox (off sourceforge) which emulates the old DOS environment. Its slow, but that's a good thing if the games run at the same speed they used to:)
lol. he says how do I becoem a better coder, and you tell him not to bother. Project management requires a lot more business analysis than you think, so its lousy advice to give someone starting out in CS.
I suggest he learns the very basics, what does it mean when the language says 'start a thread', or 'allocate memory'. Unless you know this kind of stuff you'll end up being a very inefficient coder and end up as just another ok coder who knows 1 trick. Learn the basics (even if you think they have nothing to do with your high-level languages you think you'll be coding in later), it'll make you much better than people who have learnt from a book.
yes. a solid-state hard drive is exactly that - a normal HDD that uses a different mechanism for storing data. Usually its a pinning platter, this uses non-volatile memory chips. The interface and size are the same, so you just use it as you otherwise would.
Personally, I think 64Gb is a bit much for me, I'd stick the OS and swap files on there - which come to about 10Gb on my current XP machine.
'require' is always a tricky thing in most cases, occasionally you will forget or will 'just nip to the printer', and get buttonholed by a colleague or the boss and end up spending ages away from the PC.
Better to automate it! If you cannot put a password-lock screensaver on by default, then get smartcards for the staff that must be present in a reader/usb port for the PC to unlock (which they do automatically). We looked into these for security reasons for a customer, and some are rubbish - they lock thescreen by placing a full-screen image on it instead of writing a new gina dll, but some are good.
On Windows a critical section is a 'lightweight synchronisation object' - ie it is only available within a process so only applies to threads. If you want to synchronise betwen processes you need a kernel object whether that's a semaphore, event or a mutex. I know Solaris has 'local mutexes' which I assume are the same kind of thing.
Locking a critical section is almost a no-op because its in-process only, whereas locking a mutex takes quite a bit of time relatively speaking. (ah numbers: 9800 cpu cycles for a mutex, 112 for a critical section without any contention occurring.)
Locking overhead can introduce very significant overhead, when used obviously. We had a server app that spent more time locking and switching than it did performing useful work! I wouldn't be surprised if more people start coding up threads unnecessarily now we're in the world of multiple cores and find that their apps go slower and become more unreliable.
cheers. 1 thing, if you have multiple cores with independant threads, then you're right about the overhead of context switching being better. Once you add locks between these threads then context switching becomes much worse (as the chance of hitting a locked lock is greater than when running on a single CPU)
context swithing is probably just as bad on a multi-core - you still have to save the registers which is most of the problem. On a multi-core box though, you will get more context switches as the locks get used more compared to a single core. (ie there's much more chance a switch will be needed compared to running all those threads 'sequentially' on a single core)
On a multi-core CPU you also have the issue of cache thrashing. If your thread gets preempted, when its reloaded on the other core the cache line will be invalid and has to be completely reloaded.
My points though were that threads aren't best used to complicate a consumer-producer scenario (eg, thread 1 gets data, thread 2 uses that data), unless you can service the 2nd thread while thread 1 is still processing. If you can't have the consumer doing something without that data thread 1 will provide then it is more efficient, as well as seriously simpler and therefore more maintainable, to run them in sequence.
My point is that threads are best used to do a simple thing many times over. Eg. if you have a ray tracing prog, 1 thread per core is optimum and you will get results 4x faster on a quad core. 8 threads will not get you results any faster. Similarly, if you have a webserver that wants to log to a central location, the time your first thread spends logging (ie waiting for IO) will allow the server to process other clients. But putting your logging in a thread will not make the server run any faster overall, will require some slow and fragile memory handling as you pass log lines to it (if it cannot write to the log as fast as you pump logs to it, say goodbye to your server under heavy load; or add some complex locking systems when the write queue is full which takes you back to where you started, logging in single threaded mode!).
So, unless the logging process is significantly slow, don't bother, you'll make things far more complex for no gain whatsoever.
not so, see your example of 'grab detail from the server and create a complex dialog to display it' is still single-thread of execution. If you split it into 2 threads, chances are the 2nd thread will be sitting waiting for the first thread to complete in order to have data to display!
Server devs are used to multi-threaded coding, but generally this is because on a server you write code to do one thing, and then you find that 10 people want to do that same thing at the same time (eg think of a webserver, it only takes data froma client, processes it, returns it to the client - a single threaded app effectively. But then you want to do that 1 thing for many simultaneous clients).
So I think concurrency is something that still needs a certain kind of problem to solve before it should be used. and a salutary lesson for us all: when Win95 came out, it had threads and the explorer team decided they use this cool new feature.. so every part of explorer found its way into a thread, one to draw the tree, one to draw the current folder, one for each directory to check to put a cross in the tree.. etc etc. and it was as slow as clay off a shovel. Just because you have threads doesn't mean you have to use them. Just because you have dual cores doesn't mean you have to write MT apps to use them either.
Unfortunately you say processes have their own memory protection which is better than threads that have to do their own synchronisation when accessing shared memory, but then go on about process-based shared memory needing its own additional protection.
If you need concurrency in your apps, there isn't that much between threads and processes. However, if you need interprocess-communication then you are far better off with threads, they are significantly faster wrt locking than processes as all process-based locks must be done at the OS level, using shared (and finite) system resources. Threads can just use a critical section and have done with it, almost no overhead.
Threads are not more efficient at context switching than processes, the same procedure happens whether a thread is switched, or a process is (in fact, a process is really an app with 1 thread). However, as threads can share memory more efficiently, locking is often not needed as much so they appear to be more efficient.
The best argument for threads v processes is Apache. Personally, I agree with the Apache group that Apache 2 with its thread-based model is better. They should know.
I always wondered what MS did to the display subsystem thatused up so much memory, I thought they were just useless or 'untidy' programmers and they'd optimise it when they had the chance (ie after rushing Vista out). But now I know it uses the.NET runtime and it all becomes clear...
Snowgirl.. hmm. Swedish lesbians rolling about in the early morning pristine snowfall with only the heat of their bodies to keep themselves warm....
ahem. ok, but really - if you want transparent effects, turn them on. If you don't turn them off. It is a bit much to expect the computer to realise you want transparency except when you don't. Alternatively, open a full-screen plain-coloured app (a paint app? blank-page IE?) and position your window inside it so you can see a plain colour through the effects. I doubt you take many screenshots so its not that much of a bind?
but the best bit: Phillip Rosenthal, chief technology officer of one of the companies, ISPrime, an Internet services company based in New York, said the activity had been traced to a single customer and violated the company's acceptable-use policy. He said the company's relationship with the customer, whom he would not identify, had been severed
so, one down, one to go. Its still a shame the offending company was not named, but I imagine it doesn't exist anymore, wound up and is now reborn as a differently named one.
its not so much about stopping you posting, its about being able to find out what you did after they have reason to investigate, and then using it to take action against you.
I'm sure they don't really care about this post, but I was libelling my CEO or posting racist hate statements, they would.
ah, but you are forgetting something (even with your infinite geek intelligence, how can that be?!). Most of these policies are not put into place to stop the malware, or even to stop employee's 'fun'. Most of them, especially nowadays, are there for regulatorary reasons.
Even if we ignore Sarbanes Oxley (sure, you want to get deliberately evade the company's audit systems - its possible jail time for you, my young, arrogant, potential terrorist, instant dismissal at best once you're caught.
Then there's misuse of company property. That bandwidth and pc you're using doesn't belong to you at all. Its provided so you can do your job, not for your amusement. However, I'm sure most companies don't give a damn if you email your family within reason though if makes you more productive or they consider it acceptable personal use, they will be very suspicious if you try to get around their systems.
Then you have to consider the much more serious misuse of these communications - eg. surfing for porn, hate emails etc. The company wants to track all your emails, not so they can spy on you, but so they have something that will later be used in a disciplinary or court action.
In short, why do you bother trying to hide your tracks when they are so innocent?
I just checked my centos server - default runlevel of 3 in inittab already. I guess if you install the 'server' option (or the 'nothing, I'll pick my own packages' option) then you get default runlevel of 3.
Slashdot Mirror
You are on DSL or Cable and do NOT have a firewall? Spend a few bucks and get one!
Spend money on one?! Dear oh dear..
Zonealarm (requires annoying popups asking you to buy),
Agnitum (requires reg),
Kerio (reverts to free features after 30 days),
Comodo (totally free as it's an advert for Comodo other products)
I don't know about the US, but you want an ISP that is intelligent about bandwidth. It is finite, and providing everyone with unlimited bandwidth would bankrupt the ISP. So... you need one that ignores your usage on non-peak times, that gives you a fair chunk of allowable bandwidth, and one that is upfront about its policies.
I use plusnet (in the UK), I have really unlimited usage between midnight and 4pm, 30Gb the rest of the time. They are open about their policies and have 'been in contact' with users that have used the network at full capacity 24/7. Apparently less than 1% of users use a noticeable amount of bandwidth, for these, Plusnet say: Of course, for the vast majority of people who don't use up to the usage allowance every month, a shared design like this doesn't pose any problems at all. However, the nature of any product designed in this way is that there will always be a number of customers who end up with an unsustainable long term usage pattern. This may be deliberate in some cases, but more often than not it is because after choosing a product, a customer's usage habits subsequently change. For these customers there are effectively three choices:
1. Upgrade to a different PlusNet product that is more suited to the new usage requirements.
2. Moderate peak time usage, either by reducing the amount of large downloads, or by scheduling more downloads to overnight periods when demand for interactive traffic is lower.
3. Find another ISP which is more suited to the specific usage requirements of that customer.
Plusnet did send out warning letters to a few users (adslguide has a report on it here.
It should be noted that this was 2 years ago when everyone was on 0.5Mbps lines.
So anyway, for you - if you have a shortlist, ask them about traffic shaping and capacity management.
insulation - not for anything that might touch it, but insulated from the effects of the weather. I'm sure a bare-metal wire would get quite hot in the direct sunlight, and quite cold in the night at those altitudes. I think a tough plastic coating would increase its lifespan.
Yes, I remember them too - Larry Niven used to write about them, the power would be beamed down to a base station via microwaves. You'd need to fence a large area off to prvent people straying into it and being cooked (but as he said, put up a large fence with signs on it saying "cross this fence and you will die", anyone crossing the fence gets what they deserve and the Darwin awards get a new story). Of course, in the Us, you'd probably get sued for the first fataility.
I'd also say that the energy cost of raising a 10km insulated power cable into the air would also need to be resolved too. I'd think that 10km length of power cable would weigh quite a bit, not to mention how much resistance there would be in it that would affect the power output at ground level.
Yes, but what would Joe Schmoe do? Take the machine back tot he shop, or phone their customer support and be told that the driver needed to be upgraded, with instructions on how to do it. Its still pretty crap, but this is what Joe is used to with consumer technology nowadays.
They are a little bit old by my standards, let alone by 'computer time', so you do have to expect things will start to break. I recommend DosBox (off sourceforge) which emulates the old DOS environment. Its slow, but that's a good thing if the games run at the same speed they used to :)
lol. he says how do I becoem a better coder, and you tell him not to bother. Project management requires a lot more business analysis than you think, so its lousy advice to give someone starting out in CS.
I suggest he learns the very basics, what does it mean when the language says 'start a thread', or 'allocate memory'. Unless you know this kind of stuff you'll end up being a very inefficient coder and end up as just another ok coder who knows 1 trick. Learn the basics (even if you think they have nothing to do with your high-level languages you think you'll be coding in later), it'll make you much better than people who have learnt from a book.
yes. a solid-state hard drive is exactly that - a normal HDD that uses a different mechanism for storing data. Usually its a pinning platter, this uses non-volatile memory chips. The interface and size are the same, so you just use it as you otherwise would.
Personally, I think 64Gb is a bit much for me, I'd stick the OS and swap files on there - which come to about 10Gb on my current XP machine.
what you want, me old mucka, is DosBox. And then you can have all of 6 Commander Keen episodess. Here's the first one, enjoy.
'require' is always a tricky thing in most cases, occasionally you will forget or will 'just nip to the printer', and get buttonholed by a colleague or the boss and end up spending ages away from the PC.
Better to automate it! If you cannot put a password-lock screensaver on by default, then get smartcards for the staff that must be present in a reader/usb port for the PC to unlock (which they do automatically). We looked into these for security reasons for a customer, and some are rubbish - they lock thescreen by placing a full-screen image on it instead of writing a new gina dll, but some are good.
but it was a review of multi-core CPUs. As far as the review/test is concerned, a AMD x2 4200+ is the low end chip.
at the true low-end, Intel is still the cheapest, as I can get a P3 1ghz off ebay for a fiver...
On Windows a critical section is a 'lightweight synchronisation object' - ie it is only available within a process so only applies to threads. If you want to synchronise betwen processes you need a kernel object whether that's a semaphore, event or a mutex. I know Solaris has 'local mutexes' which I assume are the same kind of thing.
Locking a critical section is almost a no-op because its in-process only, whereas locking a mutex takes quite a bit of time relatively speaking. (ah numbers: 9800 cpu cycles for a mutex, 112 for a critical section without any contention occurring.)
Locking overhead can introduce very significant overhead, when used obviously. We had a server app that spent more time locking and switching than it did performing useful work! I wouldn't be surprised if more people start coding up threads unnecessarily now we're in the world of multiple cores and find that their apps go slower and become more unreliable.
cheers. 1 thing, if you have multiple cores with independant threads, then you're right about the overhead of context switching being better. Once you add locks between these threads then context switching becomes much worse (as the chance of hitting a locked lock is greater than when running on a single CPU)
context swithing is probably just as bad on a multi-core - you still have to save the registers which is most of the problem. On a multi-core box though, you will get more context switches as the locks get used more compared to a single core. (ie there's much more chance a switch will be needed compared to running all those threads 'sequentially' on a single core)
On a multi-core CPU you also have the issue of cache thrashing. If your thread gets preempted, when its reloaded on the other core the cache line will be invalid and has to be completely reloaded.
My points though were that threads aren't best used to complicate a consumer-producer scenario (eg, thread 1 gets data, thread 2 uses that data), unless you can service the 2nd thread while thread 1 is still processing. If you can't have the consumer doing something without that data thread 1 will provide then it is more efficient, as well as seriously simpler and therefore more maintainable, to run them in sequence.
My point is that threads are best used to do a simple thing many times over. Eg. if you have a ray tracing prog, 1 thread per core is optimum and you will get results 4x faster on a quad core. 8 threads will not get you results any faster. Similarly, if you have a webserver that wants to log to a central location, the time your first thread spends logging (ie waiting for IO) will allow the server to process other clients. But putting your logging in a thread will not make the server run any faster overall, will require some slow and fragile memory handling as you pass log lines to it (if it cannot write to the log as fast as you pump logs to it, say goodbye to your server under heavy load; or add some complex locking systems when the write queue is full which takes you back to where you started, logging in single threaded mode!).
So, unless the logging process is significantly slow, don't bother, you'll make things far more complex for no gain whatsoever.
not so, see your example of 'grab detail from the server and create a complex dialog to display it' is still single-thread of execution. If you split it into 2 threads, chances are the 2nd thread will be sitting waiting for the first thread to complete in order to have data to display!
Server devs are used to multi-threaded coding, but generally this is because on a server you write code to do one thing, and then you find that 10 people want to do that same thing at the same time (eg think of a webserver, it only takes data froma client, processes it, returns it to the client - a single threaded app effectively. But then you want to do that 1 thing for many simultaneous clients).
So I think concurrency is something that still needs a certain kind of problem to solve before it should be used. and a salutary lesson for us all: when Win95 came out, it had threads and the explorer team decided they use this cool new feature.. so every part of explorer found its way into a thread, one to draw the tree, one to draw the current folder, one for each directory to check to put a cross in the tree.. etc etc. and it was as slow as clay off a shovel. Just because you have threads doesn't mean you have to use them. Just because you have dual cores doesn't mean you have to write MT apps to use them either.
Unfortunately you say processes have their own memory protection which is better than threads that have to do their own synchronisation when accessing shared memory, but then go on about process-based shared memory needing its own additional protection.
If you need concurrency in your apps, there isn't that much between threads and processes. However, if you need interprocess-communication then you are far better off with threads, they are significantly faster wrt locking than processes as all process-based locks must be done at the OS level, using shared (and finite) system resources. Threads can just use a critical section and have done with it, almost no overhead.
Threads are not more efficient at context switching than processes, the same procedure happens whether a thread is switched, or a process is (in fact, a process is really an app with 1 thread). However, as threads can share memory more efficiently, locking is often not needed as much so they appear to be more efficient.
The best argument for threads v processes is Apache. Personally, I agree with the Apache group that Apache 2 with its thread-based model is better. They should know.
I always wondered what MS did to the display subsystem thatused up so much memory, I thought they were just useless or 'untidy' programmers and they'd optimise it when they had the chance (ie after rushing Vista out). But now I know it uses the .NET runtime and it all becomes clear...
Snowgirl.. hmm. Swedish lesbians rolling about in the early morning pristine snowfall with only the heat of their bodies to keep themselves warm.. ..
ahem. ok, but really - if you want transparent effects, turn them on. If you don't turn them off. It is a bit much to expect the computer to realise you want transparency except when you don't. Alternatively, open a full-screen plain-coloured app (a paint app? blank-page IE?) and position your window inside it so you can see a plain colour through the effects. I doubt you take many screenshots so its not that much of a bind?
but the best bit: Phillip Rosenthal, chief technology officer of one of the companies, ISPrime, an Internet services company based in New York, said the activity had been traced to a single customer and violated the company's acceptable-use policy. He said the company's relationship with the customer, whom he would not identify, had been severed
so, one down, one to go. Its still a shame the offending company was not named, but I imagine it doesn't exist anymore, wound up and is now reborn as a differently named one.
its not so much about stopping you posting, its about being able to find out what you did after they have reason to investigate, and then using it to take action against you.
I'm sure they don't really care about this post, but I was libelling my CEO or posting racist hate statements, they would.
ah, but you are forgetting something (even with your infinite geek intelligence, how can that be?!). Most of these policies are not put into place to stop the malware, or even to stop employee's 'fun'. Most of them, especially nowadays, are there for regulatorary reasons.
Even if we ignore Sarbanes Oxley (sure, you want to get deliberately evade the company's audit systems - its possible jail time for you, my young, arrogant, potential terrorist, instant dismissal at best once you're caught.
Then there's misuse of company property. That bandwidth and pc you're using doesn't belong to you at all. Its provided so you can do your job, not for your amusement. However, I'm sure most companies don't give a damn if you email your family within reason though if makes you more productive or they consider it acceptable personal use, they will be very suspicious if you try to get around their systems.
Then you have to consider the much more serious misuse of these communications - eg. surfing for porn, hate emails etc. The company wants to track all your emails, not so they can spy on you, but so they have something that will later be used in a disciplinary or court action.
In short, why do you bother trying to hide your tracks when they are so innocent?
I just checked my centos server - default runlevel of 3 in inittab already.
I guess if you install the 'server' option (or the 'nothing, I'll pick my own packages' option) then you get default runlevel of 3.