Last I checked, liberalism is also based on fear. The push to ban guns, soft drinks, trans-fats, and any thing else that poses any sort of risk shows that. All politics are based on fear. It's how politicians stay in power.
Anarchism may not be, but all the other groups try to 'fear' you away from it.
> Most I know are also completely okay with universal background checks since from what myself and others have read most of the weapons used in illegal crimes are coming from legal dealers that are selling without the checks or they come from gun shows where the checks are not required.
Nowhere in the U.S. Is the proceeding true. If you are an FFL dealer YOU MUST with threat of prison fill out a 4473 and call it in. Dealers at gun shows must do a background check, it is federal law.
Now in many (most) states private individuals can sell a weapon without notification of transfer or a background check.
>A dog is pretty defenceless against a piece of meat with some horse tranquilliser in it
Fucking cokeheads doing this kind of stuff would have already shoved the tranq up there ass in a drug induced stooper. In the end all the security measures do is filter out the less determined. The dog may filter out a few young punks looking to steal a box of candy bard, but not the gang looking to steal your pseudo.
>Maybe they should move their office to a safer neighborhood. > They run an extremely lean lifestyle and profit margin
Maybe you don't understand something here. Rent. In the neighborhood you want them to move to rents can be double and triple the cost of the ghetto. If they are not making huge profits as it is, they simply can't afford to.
Locking up all the items is fine, but the problem stated was vandalism. That is a different problem then theft. A vandal may not take anything, but instead just smash stuff up. Some people are assholes.
The dogs not a bad idea, most of the gang member type i've seen seem to have a healthy fear of dogs.
An in depth defense is a VPN that only is allowed connections to port 22. You are then protected against a direct remote exploit against SSHD, if your VPN is directly exploited hopefully it runs as non-root and would require an additional system level exploit to break out of.
So your saying a 32 char password is better then a 16 char password, whoda thunk it.
Or, to rephrase that, all you've done is make it 500 trillion times harder to crack your ssh (if you're using good passwords), if you are using keyfiles for both then there pretty much needs to be a remote exploit in both the listeners.
Then pick a format you want to block with. I personally use the shorewall firewall and put them in the blacklist and keep all the traffic out (that wasn't requested by me first)
It's just iron meteors are much more likely to survive to the surface then chondrites. Stony meteors tend to explode in the atmosphere, like we saw today.
$4000 software has a big motivation to avoid being ran on VMs. Also, while the hardware may remain the same, 2 things don't. The MAC address on the VM, unless you specifically set it (it is randomized per VM by default so two copies of the same VM don't clash on a network). The processor presented to the VM is the actual processor, so on one it was was a Notebook edition processor and the other was a desktop processor. One other possibility is the software looks for virtualization drivers and will fail to run if they are installed.
> don't know what you charged them, but I doubt it was any cheaper than buying a cheap secondhand PC/laptop with a copy of Windows XP on to run that one program.
Fail.
VM's are far cheaper over the long run. And far faster. If you get a new Intel Septahexatanium 8GHz processor and SSD, copy your XP vm image over and you get all the benefits of new hardware with none of the trouble of windows freaking out about it. If it's XP-Pro just turn on RDP and any computer in the office can use it.
With the second hand PC you add all the problems that crop up with flaky (old) hardware, and all the issues of backing it up.
Are you even using VMs properly? Have a problem with the program on it, snapshot it, test it, mess it up, dump the snapshot.
Don't worry, I paid off the U.S. Government, the people in charge of your capitalist model. They are now telling your company that you must use Microsoft Office Shitpoint 2013 or you cannot renew your contracts.
Better to tie the cancel button in to another thread and poll it at a fixed interval. Polling per file copy can blow up your CPU when you app runs on a SSD that gets 100,000 IOPS. I've seen programs install slower from/to a ramdisk because of programming failures of that nature.
Just add in a single query that isn't indexed properly on accident.
In many ways, if programs could tie in to (windows for example) metrics from your local task manager and performance metrics on the database server, you'd have a much better idea whats going on. Oh I'm at 100% cpu usage, oh I'm at 100% local IOPS, oh the database server is at 100% cpu usage, etc.
> If instead the progress bar estimates the time remaining originally based on total size remaining / transfer rate + number of files remaining / per file overhead - then the original estimate is much higher and any deviations in reporting are reduced to the environmental factors that were originally quite rightly tried to be handled using moving averages etc.
That will give you a better average for sure, but it's still hard to get a 'good' average because 'per file overhead' can change dramatically dependent on where the file lands on the (spinning) hard drive. Add some fragmentation in there (which you may not have had to deal with at the beginning of the install) and things can drag out even longer unexpectedly. If you take the system IO overhead and multiply it by some made up number like 10 (100ms per file) you'd probably get closer to what occurs on the operating system (say if you're logging while writing these small files)
Very small changes effecting the IOPS when writing small file can lead to huge differences in the time to finish.
To add on to how hard it is to estimate how long something is going to take modern operating systems and hardware abstract away from the user let me give an example.
Lets say you have a computer with a lot of RAM, 128GB for example. You have file.foo you created in memory, it is 64GB. You tell the operating system to write the file to disk.
1. For the first $X hundred MB it says it's copying at a few GBs - Its filling up the memory file copy buffers. 2a. It's still fast for the first few hundred MB, it's filled up your raid card buffer. 2b. It's still fast for the few few GB, it's filled up your SSD cache or your Hybrid hard drive cache. 2c. It's fast for around 64MB, it's filled up your hard drive write cache. 3. For the first 48GB(-cachesize) of the file write speed has been pretty consistent (120MBps if you have a decent disk) 4. Something goes wrong. Even though you have 70GB free on the disk, only 48 of that was contiguous free space, now the OS has to find free spaces to put the file, seek time becomes the limiting factor. You write the last 16GB of the file between 400KBps and 20MBps depending on exactly where it lands on the disk. Almost all of your time copying is spent here even though it's the last 25% of the file.
The amount of progress is known, but the amount of time needed can change geometrically dependent on factors that are unknown to the application.
Caching screws up the estimation in the beginning and only after the cache fills up would the data rate reflects the true rates. So in order to get accurate progress bar, the software have to take that into account.
A seemingly large amount of software doesn't take in account that querying 1000 registry keys and changing the values can take a seriously long time on a spinning disk.
They also don't take in effect that written bytes are not equal. You can stream at 100MBps to a harddisk, but then drop to 400KBps on random IO. Take the same workload on a SSD and the random IO is almost invisible (in which if you were used to sampling quite often after IO operations your sampling thread can dominate the CPU time slowing down the entire operation.)
> They took recent data transfer rates, did a simple division of bytes remaining / bytes/sec and reported the expected remaining time at the most recent transfer rates. Yes, transfer rates fluxuate over time. That is the nature of things.
They also did stupid things like made the bytes/sec and average too, so if the connection silently died when the average was 100KBs for an hour it would slowly count down your average over time, even though the amount you are currently getting is 0.
The Windows 8 (yes, I know that is a curse) file copy is much, much better.
That's because the ideas to communicate are complicated.
Writing one large files IS NOT THE SAME AS Writing a bunch of small files IS NOT THE SAME AS Copying a file from the internet IS NOT THE SAME AS Copying a file from the local network IS NOT THE SAME AS Querying and updating the database IS NOT THE SAME AS Reading files from a cd-rom IS NOT THE SAME AS.......
all of which a status bar tries to sum up, poorly.
Slashdot Mirror
Last I checked, liberalism is also based on fear. The push to ban guns, soft drinks, trans-fats, and any thing else that poses any sort of risk shows that. All politics are based on fear. It's how politicians stay in power.
Anarchism may not be, but all the other groups try to 'fear' you away from it.
He didn't want to Godwin the thread.
> Most I know are also completely okay with universal background checks since from what myself and others have read most of the weapons used in illegal crimes are coming from legal dealers that are selling without the checks or they come from gun shows where the checks are not required.
Nowhere in the U.S. Is the proceeding true. If you are an FFL dealer YOU MUST with threat of prison fill out a 4473 and call it in. Dealers at gun shows must do a background check, it is federal law.
Now in many (most) states private individuals can sell a weapon without notification of transfer or a background check.
Step 1 Have a good firearm. Kill them. It works very well.
Step 2 Until Jesse Jackson and Al Sharpton show up.
Step 3 Repeat step 1.
>A dog is pretty defenceless against a piece of meat with some horse tranquilliser in it
Fucking cokeheads doing this kind of stuff would have already shoved the tranq up there ass in a drug induced stooper. In the end all the security measures do is filter out the less determined. The dog may filter out a few young punks looking to steal a box of candy bard, but not the gang looking to steal your pseudo.
>Maybe they should move their office to a safer neighborhood.
> They run an extremely lean lifestyle and profit margin
Maybe you don't understand something here. Rent. In the neighborhood you want them to move to rents can be double and triple the cost of the ghetto. If they are not making huge profits as it is, they simply can't afford to.
Locking up all the items is fine, but the problem stated was vandalism. That is a different problem then theft. A vandal may not take anything, but instead just smash stuff up. Some people are assholes.
The dogs not a bad idea, most of the gang member type i've seen seem to have a healthy fear of dogs.
You mean that you didn't ban their IP when it lit up every port like a christmas tree?
An in depth defense is a VPN that only is allowed connections to port 22. You are then protected against a direct remote exploit against SSHD, if your VPN is directly exploited hopefully it runs as non-root and would require an additional system level exploit to break out of.
So your saying a 32 char password is better then a 16 char password, whoda thunk it.
Or, to rephrase that, all you've done is make it 500 trillion times harder to crack your ssh (if you're using good passwords), if you are using keyfiles for both then there pretty much needs to be a remote exploit in both the listeners.
Make the users use long passwords or keys, then check the successful logins to make sure they aren't coming from Brazil when the employee is in Japan.
https://www.countryipblocks.net/
Then pick a format you want to block with. I personally use the shorewall firewall and put them in the blacklist and keep all the traffic out (that wasn't requested by me first)
Yes, as part of a defense in depth and not as a measure by itself.
Depends what day it occurred on.
http://en.wikipedia.org/wiki/Cuban_missile_crisis
Something like this can get easily misinterpreted.
No, they're made of iron that survives uncontrolled re-entry into Earth's atmosphere.
No. most are made of stones that accreted from dust particles. http://en.wikipedia.org/wiki/Chondrite
It's just iron meteors are much more likely to survive to the surface then chondrites. Stony meteors tend to explode in the atmosphere, like we saw today.
What VM software are you using?
$4000 software has a big motivation to avoid being ran on VMs. Also, while the hardware may remain the same, 2 things don't. The MAC address on the VM, unless you specifically set it (it is randomized per VM by default so two copies of the same VM don't clash on a network). The processor presented to the VM is the actual processor, so on one it was was a Notebook edition processor and the other was a desktop processor. One other possibility is the software looks for virtualization drivers and will fail to run if they are installed.
> don't know what you charged them, but I doubt it was any cheaper than buying a cheap secondhand PC/laptop with a copy of Windows XP on to run that one program.
Fail.
VM's are far cheaper over the long run. And far faster. If you get a new Intel Septahexatanium 8GHz processor and SSD, copy your XP vm image over and you get all the benefits of new hardware with none of the trouble of windows freaking out about it. If it's XP-Pro just turn on RDP and any computer in the office can use it.
With the second hand PC you add all the problems that crop up with flaky (old) hardware, and all the issues of backing it up.
Are you even using VMs properly? Have a problem with the program on it, snapshot it, test it, mess it up, dump the snapshot.
(I'm pretend posting as the AC above)
Don't worry, I paid off the U.S. Government, the people in charge of your capitalist model. They are now telling your company that you must use Microsoft Office Shitpoint 2013 or you cannot renew your contracts.
Thank You
Steve B.
Better to tie the cancel button in to another thread and poll it at a fixed interval. Polling per file copy can blow up your CPU when you app runs on a SSD that gets 100,000 IOPS. I've seen programs install slower from/to a ramdisk because of programming failures of that nature.
Just add in a single query that isn't indexed properly on accident.
In many ways, if programs could tie in to (windows for example) metrics from your local task manager and performance metrics on the database server, you'd have a much better idea whats going on. Oh I'm at 100% cpu usage, oh I'm at 100% local IOPS, oh the database server is at 100% cpu usage, etc.
> If instead the progress bar estimates the time remaining originally based on total size remaining / transfer rate + number of files remaining / per file overhead - then the original estimate is much higher and any deviations in reporting are reduced to the environmental factors that were originally quite rightly tried to be handled using moving averages etc.
That will give you a better average for sure, but it's still hard to get a 'good' average because 'per file overhead' can change dramatically dependent on where the file lands on the (spinning) hard drive. Add some fragmentation in there (which you may not have had to deal with at the beginning of the install) and things can drag out even longer unexpectedly. If you take the system IO overhead and multiply it by some made up number like 10 (100ms per file) you'd probably get closer to what occurs on the operating system (say if you're logging while writing these small files)
Very small changes effecting the IOPS when writing small file can lead to huge differences in the time to finish.
Did i mention I like SSDs with 20,000 IOPS : )
To add on to how hard it is to estimate how long something is going to take modern operating systems and hardware abstract away from the user let me give an example.
Lets say you have a computer with a lot of RAM, 128GB for example. You have file.foo you created in memory, it is 64GB.
You tell the operating system to write the file to disk.
1. For the first $X hundred MB it says it's copying at a few GBs - Its filling up the memory file copy buffers.
2a. It's still fast for the first few hundred MB, it's filled up your raid card buffer.
2b. It's still fast for the few few GB, it's filled up your SSD cache or your Hybrid hard drive cache.
2c. It's fast for around 64MB, it's filled up your hard drive write cache.
3. For the first 48GB(-cachesize) of the file write speed has been pretty consistent (120MBps if you have a decent disk)
4. Something goes wrong. Even though you have 70GB free on the disk, only 48 of that was contiguous free space, now the OS has to find free spaces to put the file, seek time becomes the limiting factor. You write the last 16GB of the file between 400KBps and 20MBps depending on exactly where it lands on the disk. Almost all of your time copying is spent here even though it's the last 25% of the file.
The amount of progress is known, but the amount of time needed can change geometrically dependent on factors that are unknown to the application.
Caching screws up the estimation in the beginning and only after the cache fills up would the data rate reflects the true rates. So in order to get accurate progress bar, the software have to take that into account.
A seemingly large amount of software doesn't take in account that querying 1000 registry keys and changing the values can take a seriously long time on a spinning disk.
They also don't take in effect that written bytes are not equal. You can stream at 100MBps to a harddisk, but then drop to 400KBps on random IO. Take the same workload on a SSD and the random IO is almost invisible (in which if you were used to sampling quite often after IO operations your sampling thread can dominate the CPU time slowing down the entire operation.)
> They took recent data transfer rates, did a simple division of bytes remaining / bytes/sec and reported the expected remaining time at the most recent transfer rates. Yes, transfer rates fluxuate over time. That is the nature of things.
They also did stupid things like made the bytes/sec and average too, so if the connection silently died when the average was 100KBs for an hour it would slowly count down your average over time, even though the amount you are currently getting is 0.
The Windows 8 (yes, I know that is a curse) file copy is much, much better.
That's because the ideas to communicate are complicated.
Writing one large files IS NOT THE SAME AS
Writing a bunch of small files IS NOT THE SAME AS
Copying a file from the internet IS NOT THE SAME AS
Copying a file from the local network IS NOT THE SAME AS
Querying and updating the database IS NOT THE SAME AS
Reading files from a cd-rom IS NOT THE SAME AS.......
all of which a status bar tries to sum up, poorly.