UKIP are isolationist reactionaries, better suited to the early 20th century. Imperial measures? Closer ties to the commonwealth? What do they think they have, an Empire? Lower inheritance taxes? Flat income taxes???
It reads like an imperial / aristocratic daydreamer wishlist.
Eh? You needed a controller to play them - mouse view was locked when inside a vehicle. I'd rate them around 3/10 for control playability compared to GTA4.
If you're talking about x64, the primary 64-bit consumer desktop / laptop CPU architecture, has it occurred to you that code running in the CPU's 32-bit mode also benefits from the doubled cache? It's not like the 32-bit code only uses half the cache, with 64-bit code using the full cache.
Newspapers are in the business of selling readers to advertisers, not news to readers. And don't worry, it's not going to work out well for them. They'll end up more niche and less relevant.
Bertie has a brother, Noel Ahern, who was also in government but is not currently a minister. The Slovakian minister talked rather to Dermot Ahern, who is not related to Bertie.
Many console games target 30fps, and console controllers are very ill-suited to twitch FPS gaming. No serious PC gamer would put up with such a low rate and will certainly the lag more with the richer control setup of keyboard and mouse.
Assume 60 fps, synced with 60Hz monitor. That's 16.7ms per frame, and usually means a target budget of 16.7ms per iteration in the game loop - and input is probably processed exactly once in the game loop. Consider also that many decent displays already lag by a frame or two. So in a local hardware situation, you already have a built-in lag somewhere in the region of 30ms or so, pretending there isn't any lag in the actual hardware path between devices and what the OS surfaces to apps.
Now, given the above assumptions, but factoring in your posited reactive input model (i.e. no delay from game loop), you think that's good enough? The way I see it, it can only be good enough if the round trip averages to less than 16ms or so; and even then, it's not great. I've long noticed the lag in games since moving from CRT to LCD, and I can even see the lag between moving my mouse and the pointer moving across the screen - it's small but perceptible, and is either caused by the mouse / usb / driver path or by the LCD delay.
But I can't realistically see a 16ms or so round-trip being achievable outside heavily populated areas and without lots of expensive hardware very close to local loops. As it is, Google.com is 29ms away from my machine, and it's still slow to download the front page's HTML content - (yes, I know, TCP connection, several round trips, etc.) - on the order of 200ms or so.
It seems to me that round trips on the order of 50 to 100+ms are more likely, and delays of that nature are highly, highly noticeable in twitch FPSes - especially when it comes to things like changing the view direction. Pretty much all multiplayer FPSes don't wait for a server round-trip for changing the view direction. In that situation twitch FPSes will suck.
Yes, but the Win32 loader - to take a single example - does not necessarily know how to handle copy-on-write pages logically (idata or bss) mapped in from DLLs, which is what would need to happen in a proper fork() scenario.
Re:makes windows marginally bearable
on
Cygwin 1.7 Released
·
· Score: 2, Interesting
Copy and paste: getclip and putclip. But I usually abbreviate them to p and c with a couple of wrappers.
I find Cygwin integrates really well with the rest of Windows, particularly when you mount the right drives in directories off the root, so that you have/c/ etc., but still have access to Win32 apps. I practically live in my bash/rxvt shell.
I believe I'm pretty well informed re my political views. My comment addressed the de facto power relationship, in light of the democratic and ethnographic nature of the US and its administration's public choice theoretic situation, not the P2P question at hand, however.
I think you have that power relationship backward - it's the Israelis that pressure the US, not the other way around.
The Israeli lobby in the US has strong leverage over US votes, but the US has relatively little over Israel. US administrations can never afford to be seen to be censuring Israel.
International bank operations in EU includes intra-EU transactions, between member states. The equivalent in the US, between US states, is not international.
I am far more concerned about the corporate espionage potential in this setup. The US intelligence services are already known to spy on EU companies and give that data to US companies for commercial advantage.
BTW, from my perspective your own post is more typical of Slashdot than my own: theorizing without data, postulating ignorance on the part of those with experience, and generally trying to adopt a tone of undue authority.
Software that's not fit for purpose certainly isn't a security risk, in so far as it is not used.
It's the lack of configurability that's the problem. There are very necessary reasons for putting together a unified view of multiple file systems when using ZFS, as I explained in my other posts in this thread - ZFS encourages you to create tens or hundreds of filesystems with different options, as they are cheap and draw from a unified storage pool. But such configurability is rather pointless if you can't actually use it in practice.
The block size increases as the file size increases. It starts out at 512 at doubles up to 128K. The last block in the file, however, is the same size as the general block size throughout the file. This means that a file 129K in size will take up 256K on disk:
[rupert] ~$ dd if=/dev/zero of=test bs=1024 count=129 129+0 records in 129+0 records out 132096 bytes (132 kB) copied, 0.00221615 seconds, 59.6 MB/s [rupert] ~$ du -h test 259K test
This is something they're working on to fix, but it currently can lead to quite a bit of wastage if you have many small files.
The configurable block size limits the maximum file block size, so it prevents the excess from building up:
[rupert] $ sudo zfs create tank/test [rupert] $ sudo zfs set recordsize=2K tank/test [rupert] $ sudo chmod 0777/tank/test [rupert]/tank/test$ dd if=/dev/zero of=test bs=1024 count=129 129+0 records in 129+0 records out 132096 bytes (132 kB) copied, 0.00267835 seconds, 49.3 MB/s [rupert]/tank/test$ du -h test 150K test
The configurable compression also makes a difference, but it's somewhat harder to demonstrate using data from/dev/zero or/dev/random, for obvious reasons.
But the grand extent of my samba configuration is just modifying/etc/samba/smb.conf:
... and few other fiddles, e.g. default workgroup. I'm not trying to use samba as a PDC or anything complicated. To me, it is no more or less difficult than CIFS sharing, which requires you to make sure the smbsrv module is loaded in the kernel with modinfo, loaded with add_drv, enabled with svcadm, and configured with sharemgr or zfs sharesmb= option.
I run Nexenta (OpenSolaris kernel, GNU userland) with an 8-drive ZFS file system as my main storage at home. I've struggled with the ZFS / CIFS combo, given up on it, and installed and used samba instead. I speak from hard-won experience.
ZFS has its own issues. It can be quite wasteful of space (in excess of 40% wastage) when you store small files in file systems with large block sizes. The configurability of the block size and compression, combined with the unified storage pool from which file systems can freely allocate, means that using lots and lots of file systems for different file characteristics is both desirable and possible. But the way CIFS support is implemented means that you face a major roadblock in providing a unified view. That's why I suggest that samba should be used instead.
It worked well for me, better than CIFS, particularly since I didn't need the complexity of full ACL support, and could live with traditional Unix permissions.
Using samba doesn't have the same issues. If you share a file path on one ZFS file system using Solaris CIFS, you cannot, from a client, navigate via that share from one file system to another file system, even if that other file system is mounted on a path in it. Mounted file systems just show up as empty directories.
Similarly, symlinked directories show up as symlink files, rather than directories you can browse through from the client.
Samba doesn't have either of these issues, which (for me at least) means it's a far better solution. ZFS encourages creating a lot of file systems to take advantage of configurable features like quotas, compression technique, block size, etc. If you can't mix and match those file systems into a single unified view from the perspective of clients, it means those features are a whole lot less useful.
Use samba. The CIFS support isn't worth it, unless you really need the unified account and security ACL stuff, and are prepared to take significant sacrifices for it.
Solaris combined CIFS and ZFS support is pretty flawed from other perspectives, though. Symlinks are not followed through shares, and nor are mount points last time I checked.
One of the study's co-authors was Chris Jay Hoofnagle. Hoofnagle has served as the Senior Counsel and Director of the West Coast Office of Electronic Privacy Information Center (EPIC). You haven't heard of EPIC? EPIC was the group that in 2004 argued that Gmail should be shut down: "In a letter sent to California Attorney General Bill Lockyer on Monday, the Electronic Privacy Information Center argued that Gmail must be shut down because it 'represents an unprecedented invasion into the sanctity of private communications.' "
I bought World of Goo in part based on all the interest around it, when they did their pirating blog post or whatever. I played it for a few hours, finished it in a single day IIRC. I haven't replayed it.
In terms of total game time and replay value, it was not nearly worth it. Compare it to a game like Far Cry 2 - my current replay favourite, I love crossing the beautiful countryside avoiding the guard station hazards - and there's simply no comparison. Far Cry 2 is worth 50x World of Goo.
My Toshiba Portege R500 has 3x USB, 1x S400 IEEE 1394, 1x VGA, 1x Gigabit ethernet, headphone and mic connections, and a card reader. No serial port.
My slightly older Acer cheapo has 3x USB, 1x VGA, 1x S-video, 1x 10/100 ethernet, 1x modem phone connector, headphone and mic, and a card reader. No serial port.
My GF's Eee 1005HA has 3x USB, 1xVGA, 1x 10/100 ethernet, headphone and mic, and a card reader. No serial port.
Maybe you should get out more - a visit to your local overpriced computer store should suffice.
FWIW, I would not like to work with someone who's obsessed with process. But then, I wouldn't be fond of working for a company that doesn't make software for a living, i.e. whose primary product isn't software.
The character being sick, I don't have a problem with. It makes for a good excuse not to be able to run everywhere, which most other games do by some kind of stamina meter. Apart from that, it's a source of extra missions, and adds an unpredictable element. I didn't find it unduly worrying.
The vehicles sucking? I didn't find that to be true. It's certainly useful to be able to stop another vehicle in its tracks by shooting it up, so it makes sense that a similar damage model applies to yours. About vehicles blowing up, I put that in the same category as sounds in space in Star Trek and clicking cylinder rotations on revolvers in movies, i.e. not realistic but an expectation of the genre and nothing to be worried about.
Enemies shooting at you - hey, you're playing an FPS game here. If going across the countryside was easy, there'd be no pleasure in getting through unscathed! However, if you're shooting up guard posts, you're doing it wrong. The point is to navigate the territory without ever engaging the enemy. Think like the "Thief" series of games. The map from the box helps immensely here, and I marked up mine with details about guard posts etc. so I could plan to avoid them.
The process of navigating the territory while avoiding the guards is easily my favourite part of the game.
The map as an actual thing you have to hold in your hand? Now you're just being inconsistent. You complain about vehicles blowing up, but you have a problem with having to put down your weapons to hold a map?:) I usually used the pull-out map from the box and landmarks for navigation, and occasionally used the map and GPS from the game for initial location and bearings, and of course for locating diamonds and tapes.
The game doesn't suck for me, and was more enjoyable than Crysis (and Crysis Warhead), and a whole lot more enjoyable than anything in the Half-Life 2 series.
Slashdot Mirror
UKIP are isolationist reactionaries, better suited to the early 20th century. Imperial measures? Closer ties to the commonwealth? What do they think they have, an Empire? Lower inheritance taxes? Flat income taxes???
It reads like an imperial / aristocratic daydreamer wishlist.
Eh? You needed a controller to play them - mouse view was locked when inside a vehicle. I'd rate them around 3/10 for control playability compared to GTA4.
If you're talking about x64, the primary 64-bit consumer desktop / laptop CPU architecture, has it occurred to you that code running in the CPU's 32-bit mode also benefits from the doubled cache? It's not like the 32-bit code only uses half the cache, with 64-bit code using the full cache.
Newspapers are in the business of selling readers to advertisers, not news to readers. And don't worry, it's not going to work out well for them. They'll end up more niche and less relevant.
Irish police are not British police.
Bertie has a brother, Noel Ahern, who was also in government but is not currently a minister. The Slovakian minister talked rather to Dermot Ahern, who is not related to Bertie.
Many console games target 30fps, and console controllers are very ill-suited to twitch FPS gaming. No serious PC gamer would put up with such a low rate and will certainly the lag more with the richer control setup of keyboard and mouse.
Assume 60 fps, synced with 60Hz monitor. That's 16.7ms per frame, and usually means a target budget of 16.7ms per iteration in the game loop - and input is probably processed exactly once in the game loop. Consider also that many decent displays already lag by a frame or two. So in a local hardware situation, you already have a built-in lag somewhere in the region of 30ms or so, pretending there isn't any lag in the actual hardware path between devices and what the OS surfaces to apps.
Now, given the above assumptions, but factoring in your posited reactive input model (i.e. no delay from game loop), you think that's good enough? The way I see it, it can only be good enough if the round trip averages to less than 16ms or so; and even then, it's not great. I've long noticed the lag in games since moving from CRT to LCD, and I can even see the lag between moving my mouse and the pointer moving across the screen - it's small but perceptible, and is either caused by the mouse / usb / driver path or by the LCD delay.
But I can't realistically see a 16ms or so round-trip being achievable outside heavily populated areas and without lots of expensive hardware very close to local loops. As it is, Google.com is 29ms away from my machine, and it's still slow to download the front page's HTML content - (yes, I know, TCP connection, several round trips, etc.) - on the order of 200ms or so.
It seems to me that round trips on the order of 50 to 100+ms are more likely, and delays of that nature are highly, highly noticeable in twitch FPSes - especially when it comes to things like changing the view direction. Pretty much all multiplayer FPSes don't wait for a server round-trip for changing the view direction. In that situation twitch FPSes will suck.
Other kinds of games may work better.
Yes, but the Win32 loader - to take a single example - does not necessarily know how to handle copy-on-write pages logically (idata or bss) mapped in from DLLs, which is what would need to happen in a proper fork() scenario.
Copy and paste: getclip and putclip. But I usually abbreviate them to p and c with a couple of wrappers.
I find Cygwin integrates really well with the rest of Windows, particularly when you mount the right drives in directories off the root, so that you have /c/ etc., but still have access to Win32 apps. I practically live in my bash/rxvt shell.
I believe I'm pretty well informed re my political views. My comment addressed the de facto power relationship, in light of the democratic and ethnographic nature of the US and its administration's public choice theoretic situation, not the P2P question at hand, however.
I think you have that power relationship backward - it's the Israelis that pressure the US, not the other way around.
The Israeli lobby in the US has strong leverage over US votes, but the US has relatively little over Israel. US administrations can never afford to be seen to be censuring Israel.
International bank operations in EU includes intra-EU transactions, between member states. The equivalent in the US, between US states, is not international.
I am far more concerned about the corporate espionage potential in this setup. The US intelligence services are already known to spy on EU companies and give that data to US companies for commercial advantage.
BTW, from my perspective your own post is more typical of Slashdot than my own: theorizing without data, postulating ignorance on the part of those with experience, and generally trying to adopt a tone of undue authority.
Software that's not fit for purpose certainly isn't a security risk, in so far as it is not used.
It's the lack of configurability that's the problem. There are very necessary reasons for putting together a unified view of multiple file systems when using ZFS, as I explained in my other posts in this thread - ZFS encourages you to create tens or hundreds of filesystems with different options, as they are cheap and draw from a unified storage pool. But such configurability is rather pointless if you can't actually use it in practice.
The block size increases as the file size increases. It starts out at 512 at doubles up to 128K. The last block in the file, however, is the same size as the general block size throughout the file. This means that a file 129K in size will take up 256K on disk:
This is something they're working on to fix, but it currently can lead to quite a bit of wastage if you have many small files.
The configurable block size limits the maximum file block size, so it prevents the excess from building up:
The configurable compression also makes a difference, but it's somewhat harder to demonstrate using data from /dev/zero or /dev/random, for obvious reasons.
But the grand extent of my samba configuration is just modifying /etc/samba/smb.conf:
... and few other fiddles, e.g. default workgroup. I'm not trying to use samba as a PDC or anything complicated. To me, it is no more or less difficult than CIFS sharing, which requires you to make sure the smbsrv module is loaded in the kernel with modinfo, loaded with add_drv, enabled with svcadm, and configured with sharemgr or zfs sharesmb= option.
I run Nexenta (OpenSolaris kernel, GNU userland) with an 8-drive ZFS file system as my main storage at home. I've struggled with the ZFS / CIFS combo, given up on it, and installed and used samba instead. I speak from hard-won experience.
ZFS has its own issues. It can be quite wasteful of space (in excess of 40% wastage) when you store small files in file systems with large block sizes. The configurability of the block size and compression, combined with the unified storage pool from which file systems can freely allocate, means that using lots and lots of file systems for different file characteristics is both desirable and possible. But the way CIFS support is implemented means that you face a major roadblock in providing a unified view. That's why I suggest that samba should be used instead.
It worked well for me, better than CIFS, particularly since I didn't need the complexity of full ACL support, and could live with traditional Unix permissions.
Using samba doesn't have the same issues. If you share a file path on one ZFS file system using Solaris CIFS, you cannot, from a client, navigate via that share from one file system to another file system, even if that other file system is mounted on a path in it. Mounted file systems just show up as empty directories.
Similarly, symlinked directories show up as symlink files, rather than directories you can browse through from the client.
Samba doesn't have either of these issues, which (for me at least) means it's a far better solution. ZFS encourages creating a lot of file systems to take advantage of configurable features like quotas, compression technique, block size, etc. If you can't mix and match those file systems into a single unified view from the perspective of clients, it means those features are a whole lot less useful.
Use samba. The CIFS support isn't worth it, unless you really need the unified account and security ACL stuff, and are prepared to take significant sacrifices for it.
Solaris combined CIFS and ZFS support is pretty flawed from other perspectives, though. Symlinks are not followed through shares, and nor are mount points last time I checked.
Matt Cutts already commented on this article, he has some interesting notes about the people behind the study - they also want Gmail shut down:
http://www.mattcutts.com/blog/studying-a-study/
One of the study's co-authors was Chris Jay Hoofnagle. Hoofnagle has served as the Senior Counsel and Director of the West Coast Office
of Electronic Privacy Information Center (EPIC). You haven't heard of EPIC? EPIC was the group that in 2004 argued that Gmail should be shut down: "In a letter sent to California Attorney General Bill Lockyer on Monday, the Electronic Privacy Information Center argued that Gmail must be shut down because it 'represents an unprecedented invasion into the sanctity of private communications.' "
I bought World of Goo in part based on all the interest around it, when they did their pirating blog post or whatever. I played it for a few hours, finished it in a single day IIRC. I haven't replayed it.
In terms of total game time and replay value, it was not nearly worth it. Compare it to a game like Far Cry 2 - my current replay favourite, I love crossing the beautiful countryside avoiding the guard station hazards - and there's simply no comparison. Far Cry 2 is worth 50x World of Goo.
My Toshiba Portege R500 has 3x USB, 1x S400 IEEE 1394, 1x VGA, 1x Gigabit ethernet, headphone and mic connections, and a card reader. No serial port.
My slightly older Acer cheapo has 3x USB, 1x VGA, 1x S-video, 1x 10/100 ethernet, 1x modem phone connector, headphone and mic, and a card reader. No serial port.
My GF's Eee 1005HA has 3x USB, 1xVGA, 1x 10/100 ethernet, headphone and mic, and a card reader. No serial port.
Maybe you should get out more - a visit to your local overpriced computer store should suffice.
FWIW, I would not like to work with someone who's obsessed with process. But then, I wouldn't be fond of working for a company that doesn't make software for a living, i.e. whose primary product isn't software.
Babelfish's translation sucks so badly compared to Google Translate's version that I can only suspect some ulterior motive in providing it.
The character being sick, I don't have a problem with. It makes for a good excuse not to be able to run everywhere, which most other games do by some kind of stamina meter. Apart from that, it's a source of extra missions, and adds an unpredictable element. I didn't find it unduly worrying.
The vehicles sucking? I didn't find that to be true. It's certainly useful to be able to stop another vehicle in its tracks by shooting it up, so it makes sense that a similar damage model applies to yours. About vehicles blowing up, I put that in the same category as sounds in space in Star Trek and clicking cylinder rotations on revolvers in movies, i.e. not realistic but an expectation of the genre and nothing to be worried about.
Enemies shooting at you - hey, you're playing an FPS game here. If going across the countryside was easy, there'd be no pleasure in getting through unscathed! However, if you're shooting up guard posts, you're doing it wrong. The point is to navigate the territory without ever engaging the enemy. Think like the "Thief" series of games. The map from the box helps immensely here, and I marked up mine with details about guard posts etc. so I could plan to avoid them.
The process of navigating the territory while avoiding the guards is easily my favourite part of the game.
The map as an actual thing you have to hold in your hand? Now you're just being inconsistent. You complain about vehicles blowing up, but you have a problem with having to put down your weapons to hold a map? :) I usually used the pull-out map from the box and landmarks for navigation, and occasionally used the map and GPS from the game for initial location and bearings, and of course for locating diamonds and tapes.
The game doesn't suck for me, and was more enjoyable than Crysis (and Crysis Warhead), and a whole lot more enjoyable than anything in the Half-Life 2 series.