sigh... not so, incorrect and misleading statement.
at least until NFSv4 becomes available
sigh.... the "security features" of "NFSv4" are:
Not NFSv4 specific. NFSv3 can use them too. Indeed, many other apps can use them. because:
Not even related to NFS, they're related to RPC, upon which NFS is built.
"security features" only in so far that NFSv4 makes secure RPC mechanisms (eg RPCSEC_GSS)/mandatory/, as opposed to optional (NFSv3), hence the reason why finally Linux is getting support for something more secure than plain old not-too-secure AUTH_UNIX.
See OpenBSD or Solaris (and probably a other commercial Nixen) for NFSv3 (maybe V2 as well) with strong RPC authentication methods - (ie RPCSEC_GSS) - they've had them a while.
Just because Linux does not support strong RPC auth mechanisms (upon which security of NFS, etc.. depend), does not mean NFS is insecure. Stop tarring NFS with the Linux brush. And yes, it will be good to get strong RPC security support in Linux at last.
Yes, most do. And most techies/loathe/ spam. And stories relating to spam are regulars on/. (and its the stories that bring in the readers that bring in the advertisers). So on the one hand/. editorially appear very anti-spam, but OTOH/. (or OSDN) dont have any qualms about accepting advertising money from companies in the spam business.
Its mildly analogous to a healthcare journal accepting cigarette advertisements, imo.
Oh even better, Slashdot run ads for bulk-mailers and spam, sorry, "opt-in" address list resellers. Kind of ironic considering slashdot's editorial stance on spam: "Spam is evil and bad", - unless of course its money they send you rather than spam...
in the article. Did you enter ISO-8859-9 chars or UTF-8? (/me tries to think whether ISO-8859-9 chars all map to the same UTF-8 chars.. dont think so..), eg:
1/23/4(TM)+/-(TM)O(R)EAEDJ&xN'` ""njdBBae
If you're using a recent RedHat, have a look in/usr/share/doc/kbd..../ - there are 2 files there with lots of funky UTF-8 chars (eg arabic, russian , greek and various symbols). All accessible via AltGr of course:)
Please email me in private to arrange for the transfer of the serious money, thanks.
Re:If it's raw ethernet, then it's not "IP based"
on
HyperSCSI Examined
·
· Score: 1
ooh interesting.. so the UDP version encapsulates ethernet header et al? How does that work then with the MAC addr? Why the hell does it even want to have the MAC addr's included in the HS/IP flavour? (of no use to the remote end).
Its seems really strange for HS/IP to include the ethernet header and i get the impression from the PDF on their site that this isnt the case. Can you provide a reference?
HyperSCSI/can/ be routed as it/can/ run over IP. Presumably you'd still need to translate HS/ethernet to/from HS/IP if you have HS/ethernet devices. (unless devices could simultaneously speak both HS/ethernet and HS/IP - quite possible).
Lossy transport: HS implements its own flow-control.
The biggest concern i'd have is the lack of an integrity check. Most modern link layers do have their own their own integrity check, but usually pretty basic - they can miss errors. (see Linus' story on how his sources at uni kept getting mysterious bit flips due to the server disabling checksums).
However, HyperSCSI apparently does have some provision for verifying integrity, as the docs mention there being a "hash check" of each window of data and the header contains a "digest" field. So if thats what it seems to be, a message digest of each window's data, then HS should be able to guarantee data integrity. (and as it can also do authentication, it should provide good bit of security too, depending on the message digest algo).
So:
IP capable? (hence routable) - tick Flow control (deal with packet loss)? - tick Data Integrity? - tick (probably) Authentication? - tick (optional) Free from overhead of TCP? - tick
Sounds like HyperSCSI could be/very/ useful.
Re:If it's raw ethernet, then it's not "IP based"
on
HyperSCSI Examined
·
· Score: 1
Its both apparently, ie can run both inside ethernet (HS/IP, frame type 0x889a and IP (HS/IP - udp port 5674). It apparently implements its own flow-control and optional authentication/encryption framework.
RTFA? yes, perhaps you should have but instead you're moderated as insightful. (meta-mods?)
Re:If it's raw ethernet, then it's not "IP based"
on
HyperSCSI Examined
·
· Score: 1
HyperSCSI can also run over IP (ie UDP presumably) according to their docs.
Why? Because they dont share your sense of humour? The perpetrators of practical jokes on people they know will not find them funny are quite often the arseholes imo. Play pranks on like-minded folk.
Basically, LBX is crap at reducing round-trip operations. About the only real value in LBX is the compression, which is something you could also get from an SSH tunnel (and indeed SSH tunnel's can/beat/ LBX). However the real killer to X performance is latency, even if you have plenty of bandwidth, X will react very poorly in the face of high-latencies (internet range latency, 50ms+), as its quite "chatty". LBX does very little to improve latency by eliminating round-trip operations - it has "smarts" for only a very very few simple X operations (3 AIUI). In essence, LBX works for bandwidth constrained links (as does SSH), but does little for latency-challenged links - and latency is what hurts X the most, and latency is what most people do not have on internet links. (And on bandwidth constrained links, you end up with latency problems too, as you have to wait for pixmaps and other large X objects to transfer.).
IOW, LBX is pretty useless. Latency is probably where this new NX protocol has made the biggest gains.
The 486 DX-4 ran at 100MHz, and I'm almost sure there were non-Intel 486 clones that ran at at least 120MHz. Unfortunately my awful memory cant think of the name(s). Then there's overclocking, as you mention. (100 to 133 isnt a/huge/ stretch, and from 120, even less so.).
It wasnt NT which crashed, it was the application. As for badly written applications crashing Linux, yes actually, its damn easy. (NB: I'm actually very pro-Linux).
I'm not an MS fan, but to be fair, my vague recollection is that was an application problem. NT can do as much about bad apps crashing as Linux or any other decent OS can. Ie it wasnt NT's fault - it was 3rd party control software running on NT. (iirc).
The answer to the story, even if the hard drive is blank, is most likely "yes", especially if its SCSI - just look at the firmware for the drive. I know for a fact Seagate disks run a real-time operating system (BOS or somesuch). As ATA gains ever more SCSI-like features (tagged commands and queueing), even modern ATA disks probably too run an embedded OS.
Indeed, it does rather depend on your definition of client, doesn't it?:)
By your definition, the traditional network client/server computing definition, a teletype/terminal is not a client. You could though make an argument that client should be read in the more abstract sense, ie the terminal acts as a client to the server for the user. Indeed, that would make more sense, as a thin client tends to imply hardware being involved:).
With the qualifier thin applied, the traditional network client/server definition no longer really makes sense. I've never heard of software programmes being described as 'thin client' at least:)
Originally, "thin clients" were just simple diskless network computers designed to run server-based Java applications.
Wow... NEC must have a time-machine so, cause I remember using a thin-client back in 95 or 96 or so when Java was still at the neat idea stage.
The original thin clients were the old tele-typewriters, followed by the CRT terminals of course, followed by the X-terminals. Of course, you meant thin client in the Windows sense, where indeed, many do run Java:).
Windows NT 4.0 on alpha AXP did/not/ support 64bit addressing, presumably neither did 3.5 (very very unlikely). Pointers on WinNT AXP were 32 bit in size.
MS did apparently have in-house 64 bit builds of Windows NT '5.0' on alpha, but that was/after/ MS had already stopped supporting NT on alpha - ie an internal porting exercise to prepare NT2k for 64 bit architectures (primarily IA64 in mind at that time).
Re:What is the difference between MI5 and MI6 anyw
on
Cracking GSM
·
· Score: 1
MI5 is counter-intelligence, ie operating/within/ Britain to counter security/intelligence threats. MI5 were involved in efforts to counter IRA activity, as well as tapping most phone and other comms to Rep. of Ireland.
MI6 are intelligence, ie gathering intelligence on external parties. Equivalent of the US CIA.
Apparently they've changed their names, according to another poster.
Why? Glue records. You are _meant_ to receive certain As from the parent servers of a domain delegated to nameservers which live within its own namespace.
However, you're missing a crucial part: when you ask the delegating server for the NS records, the glue A records are given out in the additional section, not in the answer section.
The ISC patch disregards/authoritative/ non-apex data from zones configured as delegate only. however, it can still make use of additional data (ie glue). Glue records are never queried directly AFAIK when a DNS server is sending queries to determine the set of authoratitive servers for a zone, so the patch does not cause any problems.
Again, like I said, I/did/ check the parsing was correct. Again, the spamcop DNSBl listings are/not/ influenced by whether the user selects or deselects reports.
When someone at Spamcop notices an error, they send a warning message to the person who sent in the false report. If too many errors arise from one reporter, then their account is suspended.
Great system, unfortunately is/spamcop's/ software (wrt to their DNSBl) which makes the error - not the reporter. Eg, Spamcop put far too much faith in their chaintest.
Yes, I'm aware of that page. Read it very carefully. Now read what I wrote, now consider that I have had experience of spamcop listing my ISP, despite me/never/ having clicked any of the reports to include reporting on my ISP.
Slashdot Mirror
sigh... not so, incorrect and misleading statement.
at least until NFSv4 becomes available
sigh.... the "security features" of "NFSv4" are:
See OpenBSD or Solaris (and probably a other commercial Nixen) for NFSv3 (maybe V2 as well) with strong RPC authentication methods - (ie RPCSEC_GSS) - they've had them a while.
Just because Linux does not support strong RPC auth mechanisms (upon which security of NFS, etc.. depend), does not mean NFS is insecure. Stop tarring NFS with the Linux brush. And yes, it will be good to get strong RPC security support in Linux at last.
Yes, most do. And most techies /loathe/ spam. And stories relating to spam are regulars on /. (and its the stories that bring in the readers that bring in the advertisers). So on the one hand /. editorially appear very anti-spam, but OTOH /. (or OSDN) dont have any qualms about accepting advertising money from companies in the spam business.
Its mildly analogous to a healthcare journal accepting cigarette advertisements, imo.
Oh even better, Slashdot run ads for bulk-mailers and spam, sorry, "opt-in" address list resellers. Kind of ironic considering slashdot's editorial stance on spam: "Spam is evil and bad", - unless of course its money they send you rather than spam...
Well, your chars came out as:
/usr/share/doc/kbd..../ - there are 2 files there with lots of funky UTF-8 chars (eg arabic, russian , greek and various symbols). All accessible via AltGr of course :)
1/41/23/4''xaae(R)uuiooaBdoae(C)nc
in the article. Did you enter ISO-8859-9 chars or UTF-8? (/me tries to think whether ISO-8859-9 chars all map to the same UTF-8 chars.. dont think so..), eg:
1/23/4(TM)+/-(TM)O(R)EAEDJ&xN'`
""njdBBae
If you're using a recent RedHat, have a look in
Its GNU/Linus, you insensitive clod!
What, like this or maybe this?
Please email me in private to arrange for the transfer of the serious money, thanks.
ooh interesting.. so the UDP version encapsulates ethernet header et al? How does that work then with the MAC addr? Why the hell does it even want to have the MAC addr's included in the HS/IP flavour? (of no use to the remote end).
Its seems really strange for HS/IP to include the ethernet header and i get the impression from the PDF on their site that this isnt the case. Can you provide a reference?
HyperSCSI /can/ be routed as it /can/ run over IP. Presumably you'd still need to translate HS/ethernet to/from HS/IP if you have HS/ethernet devices. (unless devices could simultaneously speak both HS/ethernet and HS/IP - quite possible).
/very/ useful.
Lossy transport: HS implements its own flow-control.
The biggest concern i'd have is the lack of an integrity check. Most modern link layers do have their own their own integrity check, but usually pretty basic - they can miss errors. (see Linus' story on how his sources at uni kept getting mysterious bit flips due to the server disabling checksums).
However, HyperSCSI apparently does have some provision for verifying integrity, as the docs mention there being a "hash check" of each window of data and the header contains a "digest" field. So if thats what it seems to be, a message digest of each window's data, then HS should be able to guarantee data integrity. (and as it can also do authentication, it should provide good bit of security too, depending on the message digest algo).
So:
IP capable? (hence routable) - tick
Flow control (deal with packet loss)? - tick
Data Integrity? - tick (probably)
Authentication? - tick (optional)
Free from overhead of TCP? - tick
Sounds like HyperSCSI could be
Its both apparently, ie can run both inside ethernet (HS/IP, frame type 0x889a and IP (HS/IP - udp port 5674). It apparently implements its own flow-control and optional authentication/encryption framework.
RTFA? yes, perhaps you should have but instead you're moderated as insightful. (meta-mods?)
HyperSCSI can also run over IP (ie UDP presumably) according to their docs.
Why? Because they dont share your sense of humour? The perpetrators of practical jokes on people they know will not find them funny are quite often the arseholes imo. Play pranks on like-minded folk.
Basically, LBX is crap at reducing round-trip operations. About the only real value in LBX is the compression, which is something you could also get from an SSH tunnel (and indeed SSH tunnel's can /beat/ LBX). However the real killer to X performance is latency, even if you have plenty of bandwidth, X will react very poorly in the face of high-latencies (internet range latency, 50ms+), as its quite "chatty". LBX does very little to improve latency by eliminating round-trip operations - it has "smarts" for only a very very few simple X operations (3 AIUI). In essence, LBX works for bandwidth constrained links (as does SSH), but does little for latency-challenged links - and latency is what hurts X the most, and latency is what most people do not have on internet links. (And on bandwidth constrained links, you end up with latency problems too, as you have to wait for pixmaps and other large X objects to transfer.).
:) )
IOW, LBX is pretty useless. Latency is probably where this new NX protocol has made the biggest gains.
For the problems on LBX, read it straight from the horses mouth in this paper by Keith Packard and Jim Gettys on X Window System Network Performance", LBX is discussed specifically towards the end. (Guess where I got the info for my first paragraph?
Why not?
/huge/ stretch, and from 120, even less so.).
The 486 DX-4 ran at 100MHz, and I'm almost sure there were non-Intel 486 clones that ran at at least 120MHz. Unfortunately my awful memory cant think of the name(s). Then there's overclocking, as you mention. (100 to 133 isnt a
It wasnt NT which crashed, it was the application. As for badly written applications crashing Linux, yes actually, its damn easy. (NB: I'm actually very pro-Linux).
I'm not an MS fan, but to be fair, my vague recollection is that was an application problem. NT can do as much about bad apps crashing as Linux or any other decent OS can. Ie it wasnt NT's fault - it was 3rd party control software running on NT. (iirc).
The answer to the story, even if the hard drive is blank, is most likely "yes", especially if its SCSI - just look at the firmware for the drive. I know for a fact Seagate disks run a real-time operating system (BOS or somesuch). As ATA gains ever more SCSI-like features (tagged commands and queueing), even modern ATA disks probably too run an embedded OS.
Indeed, it does rather depend on your definition of client, doesn't it? :)
:).
:)
By your definition, the traditional network client/server computing definition, a teletype/terminal is not a client. You could though make an argument that client should be read in the more abstract sense, ie the terminal acts as a client to the server for the user. Indeed, that would make more sense, as a thin client tends to imply hardware being involved
With the qualifier thin applied, the traditional network client/server definition no longer really makes sense. I've never heard of software programmes being described as 'thin client' at least
Originally, "thin clients" were just simple diskless network computers designed to run server-based Java applications.
:).
Wow... NEC must have a time-machine so, cause I remember using a thin-client back in 95 or 96 or so when Java was still at the neat idea stage.
The original thin clients were the old tele-typewriters, followed by the CRT terminals of course, followed by the X-terminals. Of course, you meant thin client in the Windows sense, where indeed, many do run Java
WinNT 3.5 and 4.0 has 64 bit Alpha support
/not/ support 64bit addressing, presumably neither did 3.5 (very very unlikely). Pointers on WinNT AXP were 32 bit in size.
/after/ MS had already stopped supporting NT on alpha - ie an internal porting exercise to prepare NT2k for 64 bit architectures (primarily IA64 in mind at that time).
Windows NT 4.0 on alpha AXP did
MS did apparently have in-house 64 bit builds of Windows NT '5.0' on alpha, but that was
MI5 is counter-intelligence, ie operating /within/ Britain to counter security/intelligence threats. MI5 were involved in efforts to counter IRA activity, as well as tapping most phone and other comms to Rep. of Ireland.
MI6 are intelligence, ie gathering intelligence on external parties. Equivalent of the US CIA.
Apparently they've changed their names, according to another poster.
That approach is fucking dangerous.
/authoritative/ non-apex data from zones configured as delegate only. however, it can still make use of additional data (ie glue). Glue records are never queried directly AFAIK when a DNS server is sending queries to determine the set of authoratitive servers for a zone, so the patch does not cause any problems.
Why? Glue records. You are _meant_ to receive certain As from the parent servers of a domain delegated to nameservers which live within its own namespace.
However, you're missing a crucial part: when you ask the delegating server for the NS records, the glue A records are given out in the additional section, not in the answer section.
The ISC patch disregards
Again, like I said, I
When someone at Spamcop notices an error, they send a warning message to the person who sent in the false report. If too many errors arise from one reporter, then their account is suspended.
/spamcop's/ software (wrt to their DNSBl) which makes the error - not the reporter. Eg, Spamcop put far too much faith in their chaintest.
Great system, unfortunately is
Yes, I'm aware of that page. Read it very carefully. Now read what I wrote, now consider that I have had experience of spamcop listing my ISP, despite me
You are confusing Spamcop's reporting service with Spamcop's DNSBl.
You have no influence on what goes into the DNSBl. (other than by not using spamcop).