NFS, SMB, and all the other file-serving protocols are file-based. Clients open files on the file server, and do reading and writing from/to those files. The file server is responsible for security, making sure the client has proper permission to access their files. (cat/etc/passwd)
iSCSI is similar to SCSI and IDE: it is block-based. Computers do reads and writes of individual disk sectors, addressed by number, and not in terms of files. It is below the filesystem. There is no security in terms of individual users here, because once the disk is opened, it is wide open. It is much faster than file-based access, though, which makes it popular for databases and such. (cat/dev/hda)
Your file server does a great job at both file-based and block-based access. The server serves up shares and files over file-based protocols, allowing users to connect. Internally, a filesystem is applied to the disks, and the files are translated into individual low-level accesses to read and write various disk sectors. These reads and writes to the disk take place over a block-based protocol.
Everything has its place, and it all fits together... hopefully!
It is basically a fast and tight network to connect computers with storage devices. It does exactly what your IDE or SCSI cable does, except over a network.
You are right. iSCSI will be used over LAN and WAN links. Hopefully this will be done in a way that is tunneled and secure, similar to how a VPN works today. Allowing outside users to arbitrarily inject packets into a SAN network would be a Bad Thing.
A good application of iSCSI over a remote link is to bridge multiple iSCSI SAN networks together. This combines storage devices in multiple locations into one logical network. This would be useful for applications such as remote backup, mirroring, database replication, and so on.
http://www.adaptec.com/worldwide/product/markedi to rial.html?sess=no&prodkey=ipstorage_sra_asic&type= Common&cat=/Common/IP+Storage
It is also useful as an interconnect for bridging multiple Fibre Channel SAN networks together, and translating between iSCSI and Fibre Channel.
No, the SCSI equivalent of SATA is called "SAS". Serial Attached SCSI.
http://www.scsita.org/sas/FAQ.html
What's really cool is that SAS and SATA share the same cabling and interface! SAS is a superset of SATA, that adds SCSI's features (multiple devices per port, and so on) to the basic one-device-per-port SATA design. The nice thing is that you can use cheap SATA drives on a SAS setup! This should be good for RAID. Think of SAS as "SATA Plus".
Here's a quote from the link above:
"Serial Attached SCSI complements Serial ATA by adding device addressing, and offers higher reliability and data availability services, along with logical SCSI compatibility. It will continue to enhance these metrics as the specification evolves, including increased device support and better cabling distances. Serial ATA is targeted at cost-sensitive non-mission-critical server and storage environments. Most importantly, these are complementary technologies based on a universal interconnect, where Serial Attached SCSI customers can choose to deploy cost-effective Serial ATA in a Serial Attached SCSI environment."
iSCSI will be used in a SAN environment. This is only between computers and storage devices, and not betwen computers and the outside world. I think you're confusing SAN with LAN.
It's like how SCSI is set up today on a single computer: there's really no way to get access to the SCSI bus without first gaining access to the host computer. The LAN and the SCSI bus are two entirely different things, separated by the host computer.
When iSCSI is used, this separation should be preserved. The network that is set up for iSCSI, your SAN, should be kept separate from your main LAN. Think of it as a private network that is visible only from your file servers that have a need to access storage devices directly.
Think of a SAN as equivalent to your IDE or SCSI cable. A SAN network typically uses a block-based protocol, that will read and write individual disk sectors without regards to filesystems, access control, and so on. This is designed for maximum speed, not security. It is the job of the file server to translate this into file-based access for outside clients, and enforce the appropriate file permissions.
And yes, you should definitely have good security on your file servers....
http://www.adaptec.com/worldwide/common/index.ht ml ?prodkey=ipstorage_index1
iSCSI is useful as an interconnect in a SAN environment. The storage devices exist as their own node on the network, independently of the computers they are attached to. This is good for reliability (can replace the disk independently of the computer if it fails, and vice versa), configuration flexibility, and many other useful things.
iSCSI is nice because it uses standards that are well understood (Ethernet, TCP/IP) instead of custom networks like Fibre Channel. This should make SAN networks cheaper and more common, as well as providing an easy way to bridge a SAN network over the Internet (firewalled and encrypted, of course).
The only difference between a LAN and a SAN will be what you use it for!
When reading the recent Supreme Court decision, after the initial sorrow, I thought of this myself.
Congress has extended copyright in an effort to protect Steamboat Willie and a few other very profitable creations of the late 1920's. The vast majority of content created at that time is unfortunately decaying in vaults and warehouses, or forgotten completely. It can't be brought back alive in the public domain, because of the copyright extension.
The idea of a registry is great. People might gladly pay the tax to be listed in the registry, to make it easier to be found! When there is a desire to reuse an old creation during a new production, and pay money to that copyright holder, oftentimes the difficulty of finding the legitimate copyright holder is too great. Nobody wants to take the risk of having somebody crawl out of the woodwork after a production is completed and distributed worldwide, and sue for damages. So the use doesn't occur, which is a lose-lose situation. The idea of a registry fixes this! I can see the issuing of copyright numbers, similar to current patent numbers.
(C) #10,000,000 - 2003 Krellan
This compromise idea is great! It allows the public domain calendar to become unfrozen and finally start advancing past 1923. It protects Disney's big moneymakers. And it generates some extra revenue too!
The minute details would still need to be ironed out. What exactly constitutes a copyrighted work? If I create an album of music, do I have to pay the tax on each individual song, and/or on the album as a whole? If I write a software package, does each program, module, etc. need its own separate copyright registration?
Rolling all the way back to 50-year expiration would be too much to realistically expect now, I think. I support going back 80 years. This between the pre-SBCTEA and SBCTEA time periods. And this is exactly where the public domain calendar is currently stalled at (1923), so it makes sense to start here. There would be no sudden rush to register works in danger of immediately expiring.
Copyright law is different for individuals vs. companies, and this might need to be sorted out before a registry can be created. The "death plus X years" rule might need to be standardized and shortened to just "X years". Otherwise it will be a source of confusion: would works revert to their individual creators after the corporate copyright time expires, and if so, who gets the copyright when there are multiple people involved?
I hope the copyright tax is fair: not insignificant, but also not painful to an average individual person. A fee of $50 to $100 per work seems appropriate. It might be a lot of paperwork to assess this annually. I would much prefer the idea of assessing it every 5 years. As others have suggested, this would make it too easy to simply lock up content forever, so I also support increasing this over time. Mathematically doubling, as some have suggested, would quickly get ridiculous. As a compromise, a simple progression: $50 for the first 5 years, $100 for the next 5 years, then $150, $200, $250, and so on. If this outpaces inflation, it will provide an incentive for some people to simply drop it and let their work enter the public domain.
I am going to write my representatives. I hope that one of them is brave enough to introduce a bill!
This site has another PCI device/vendor ID database.
Better save it while you can! There are download links available to get the entire table. Since the PCI-SIG has crushed the old yourvote.com site, there's no telling how long they will let this other site remain up, since it has similar content.
You might have the file already!
/usr/share/pci.ids
Download the latest version anyway, so your distribution is up to date. This file provides the human-readable names for tools such as lspci.
See the rant from the last time this appeared on Slashdot, roughly August 2001, and my embellishments to it. I added a lengthy 12-step process for installing RealPlayer that is the best that can be done for disabling spam/spyware given the few options they give you:
Also look at this funny picture that someone anonymously posted long ago, when a frustrated user decorated Real's building! If anyone knows the original source, I'd love to know it.
I would be interested in a standalone box (no PC connection or software required) that converts HDTV to VGA. It would output to any ordinary PC monitor that accepts VGA. Many people have extra monitors lying around and it would be very cost effective to simply convert these into HDTV sets instead of buying new HDTV gear.
This ideal box would have:
* Antenna input, for the raw signal from the antenna * HDTV tuner, with selectable channel (including selectable feed if channel is multiplexed) * VGA output, to an ordinary PC monitor * Audio output, with standard RCA jacks (or optional digital jacks) for sound * Downscaler, to downgrade to a lower resolution in case the VGA monitor does not support a given resolution (the VESA DDC standard would be used to query the VGA monitor and detect what resolutions it supports, without needing user configuration) * Optional remote control for the HDTV tuner
Simple, cost effective, does not require purchase of a monstrously huge and expensive set in order to watch HDTV, and does not involve the complication and setup hassles of a PC.
The 4 steps when the server finishes sending data and closes the connection, from the article:
Client Server
<-- FIN ACK --> FIN -->
<-- ACK
When the server has no more data, it sends FIN.
The server should not be allowed to send more data after the FIN! This is a violation of the TCP spec. Otherwise, how would clients truly know whether or not the server had more data to send?
TCP does support something called "half close". It is possible to indicate that you have no more data to send, but that you are still willing to receive data. This is why both sides must send FIN, in order to cleanly close the connection. If one side sends FIN but the other doesn't, the connection remains open, but data can only flow in one direction (sending from the side that did not send the FIN). This is useful for cleanly shutting down connections and making sure that both sides receive all the data they were expecting.
In the example from the article, when the client receives a FIN but does not send a FIN of its own, this is legal: the TCP connection now is one way, and data can only be sent from the client to the server. The server is not allowed to send more data. So, if IIS is doing this, it is breaking the spec. It is important to note that the client is doing nothing wrong in this case.
Yes, that's exactly the bad decision that was made back then. Sectors are numbered starting with 1, but cylinders and heads are numbered starting with 0! Bizarre.
If it's truly a bug in Linux itself, instead of a bug in dd, then it should be even easier to fix. I hope this gets fixed in 2.5!
I read the NIST document and noticed they mentioned a limitation of dd.
When copying, dd only copies entire blocks. If there is an incomplete block of information remaining at the end of the disk, for example, dd will not copy that last block at all.
Since dd defaults to a block size of 1024 bytes, and PC hard drives use a sector size of 512 bytes, this could happen. In this case, dd will not copy the final sector of the hard disk, as it is an incomplete block.
Because of a stupid decision made decades ago, traditional PC hard disk addressing uses 63 sectors per track, not 64. Therefore, odd total numbers of sectors are common. Modern addressing does away with CHS and just numbers all sectors from 0 to the end of the disk (many millions, in most cases). Still, because of the legacy of having 63 sectors per track, many disks have an odd total number of sectors.
It would be nice if dd had an option to correctly copy a partial block at the end of the source. If there is an incomplete block, it should simply copy one byte at a time until there are no more bytes to copy.
This would be easy to add to dd. Has it been done already? If so, it should be documented. Making it the default behaviour might break existing applications, so have it as an option that is highly recommended.
Read the above post more carefully. The spammer was successful in spoofing the IP address of a TCP session, because he controlled both the dialup account and the high-speed account.
SYN from the dialup account.
SYN+ACK from the helpless email server back to the dialup account. Dialup account now has observed both sequence numbers.
ACK from the dialup account, and the SMTP transaction begins.
As sending mail consists mostly of uploading, upload packets to the server are forged from the high-speed account to the server. The dialup account only needs to receive the ACK for the sent data, and the SMTP responses from the server. The spammer uses both the dialup and the high-speed accounts in tandem to keep the connection alive, in effect intentionally hijacking his own TCP connection.
Very clever! The spammer must have had some help in setting up a scheme like this. I don't think he'd be smart enough to write the software on his own.
Another use of atomic checkins is checking in more than one file at a time, especially when checking in two files whose changes depend on each other. In my experience at several CVS shops, the build sometimes breaks simply because of unfortunate timing: checking out the tree while someone else is in the middle of checking in a series of files. Most shops deal with this manually, by having certain rules, such as no checkins allowed at all during a certain hour of the night.
If there was a way in CVS to begin a transaction, then do multiple checkins, then commit/rollback that transaction atomically, that would be wonderful. It would be impossible for one person to check out someone else's partial checkin.
If Subversion is getting this feature, or even has this already, it will be one of the best "selling points" to replace CVS!
The agreement on the surface seems reasonable and fair: 8% of gross income or 5% of non-bandwidth-related expenses, whichever is greater.
However, the retroactive minimum fees are killer!
It will cost a minimum of $8,500.00 for a long-lived webcasting station to legally get back on the air. A fee of $2,000.00/year for years 1999-2002, plus a prorated fee of $500.00 for 1998 (the DMCA did not take effect until October 1998). Many small time radio stations and hobbyist stations cannot afford this!
I'm glad the law gives college radio stations and other nonprofits extra time to work this out.
If stations five years ago had known about the killer retroactive fees that would be coming due now, very few of them would have continued webcasting after that fateful day in October 1998!
To me, the solution is to forgive the retroactive fees, in exchange for agreeing to pay the new fees for years 2003 and beyond.
It seems too many people distrust spam filters because of the chance of accidentally blocking an important legitimate message as if it were spam.
Many spam filters are strictly binary: a message is either spam, or not spam. This is not ideal, because "gray area" messages - between these two extremes - will likely not be sorted correctly.
I propose adding a new sort option to email clients.
Sort by Spam Probability
This would be an additional field that can be displayed in a message list, similiar to "To", "From", "Subject", and the like. Like the article, probabilities would range from 99% (almost certain spam) to 1% (most likely an innocent message). Notice that 100% accuracy either way is not claimed.
This way, the user can see up front the messages that are most likely not spam. The spam messages will be relegated to the bottom of the list, possibly colored to indicate their likelihood of being spam. If there is a message in the "gray area", it will most likely appear in the list between the legitimate messages and the spam, so the user will have a chance to see the message and make a decision, without the message being lost in the shuffle.
This would be a great feature. I hope this gets into Mozilla's mail client.
(BTW, another feature that would be great to see in mail clients would be datestamping of the actual time the message was downloaded. Many spammers, and innocent people with misconfigured clocks, send emails with wild dates that are not to be trusted. You can see this in yearly archives of GNU "mailman" mailing lists! Datestamping emails as they are downloaded will also keep mailboxes in order when sorted by date, as newly arrived messages will always be at the bottom, instead of being scattered throughout the inbox. But sorting by spam probability will probably become more popular than sorting by date....)
Should not be 3.0 until 64-bit through and through
on
Linux Kernel 3.0?
·
· Score: 5, Insightful
I believe the Linux kernel should not be called 3.0 until it is 64-bit through and through.
The difference between 1.x and 2.x was a major architectural change: multiprocessor capability and portability to different platforms. The difference of 3.x should be equally as large: widening of all interfaces and data structures that are currently reaching their limits.
This includes 64-bit memory access, 64-bit file size access, 64-bit block counts on filesystems, and so on. Important external interfaces such as networking and filesystems must also be widened. A fully complete and robust IPv6 stack is a must: something that isn't quite there yet, but is getting close.
Essentially all fields in stat() require widening! Major and minor device numbers desperately need more room. Inode numbers and file size 64-bit, of course. Timestamps need to fix the Y2038 problem: 64-bit, possibly with added precision as well (to guarantee each file can be unambiguously sorted by time even on fast systems with such applications as parallel make). Security needs to be more fine grained (full ACL support). 32-bit UID and GID numbers. And finally, the filename itself needs to have full Unicode support without loss of field width (255 Unicode characters should be accepted). The output of the ls(1) command is a call to action: essentially every field there is in need of widening!
The main difference should be in the defaults: currently, standard stat() file limits and IPv4 are the defaults, and programs must go out of their way to request larger sizes (O_LARGEFILE) and IPv6. The programming model should be changed to provide programs with the widened resources as standard. This will take a long time, and is a gradual evolution, so there is a definite need for 2.6 and possibly 2.8 as transitional steps. The widening of these critical system resources is probably the main thing keeping Linux from large commercial UNIX installations!
I viewed the same link as you, and got these top 3 results:
antiw*r.com "leave china alone" english.peopledaily.com.cn "foreign f***n g**g activists asked to leave" hyperm*rt.net "yankees leave china alone" And then some news articles about the North K*reans seeking asylum in China then moving to South K*rea.
I starred out things above so hopefully the Great Firewall of China won't block this post and you can read it.
I have a friend in China and we often ICQ each other to test the firewall and verify things he's researching, and we've ran into several surprising differences....
Comparing two copies and averaging out the watermark is easy... provided you can crack the encryption. Once you do that, it's game over, and the studio has a lot more than the watermark to worry about.
I hope they start the clock running when you first decide to view the movie, not when it's downloaded. I can see having a period like 30 days in which the movie file would be valid on your system, ready to be viewed at any time, at which point the 24-hour timer would start. This solves the problem of not having enough time at the moment, which often happens when renting movies from the video store.
Want to watch the movie more than a few times? Buy it on DVD at full price, for unrestricted viewing (region codes notwithstanding). In my experience, there are very few movies that are worth watching more than once, and those few are keepers!
Slashdot Mirror
NFS, SMB, and all the other file-serving protocols are file-based. Clients open files on the file server, and do reading and writing from/to those files. The file server is responsible for security, making sure the client has proper permission to access their files. /etc/passwd)
/dev/hda)
(cat
iSCSI is similar to SCSI and IDE: it is block-based. Computers do reads and writes of individual disk sectors, addressed by number, and not in terms of files. It is below the filesystem. There is no security in terms of individual users here, because once the disk is opened, it is wide open. It is much faster than file-based access, though, which makes it popular for databases and such.
(cat
Your file server does a great job at both file-based and block-based access. The server serves up shares and files over file-based protocols, allowing users to connect. Internally, a filesystem is applied to the disks, and the files are translated into individual low-level accesses to read and write various disk sectors. These reads and writes to the disk take place over a block-based protocol.
Everything has its place, and it all fits together... hopefully!
Storage Area Network!
/ 0, ,sid5_gci212937,00.html
http://searchstorage.techtarget.com/sDefinition
It is basically a fast and tight network to connect computers with storage devices. It does exactly what your IDE or SCSI cable does, except over a network.
You are right. iSCSI will be used over LAN and WAN links. Hopefully this will be done in a way that is tunneled and secure, similar to how a VPN works today. Allowing outside users to arbitrarily inject packets into a SAN network would be a Bad Thing.
i to rial.html?sess=no&prodkey=ipstorage_sra_asic&type= Common&cat=/Common/IP+Storage
A good application of iSCSI over a remote link is to bridge multiple iSCSI SAN networks together. This combines storage devices in multiple locations into one logical network. This would be useful for applications such as remote backup, mirroring, database replication, and so on.
http://www.adaptec.com/worldwide/product/marked
It is also useful as an interconnect for bridging multiple Fibre Channel SAN networks together, and translating between iSCSI and Fibre Channel.
No, the SCSI equivalent of SATA is called "SAS". Serial Attached SCSI.
http://www.scsita.org/sas/FAQ.html
What's really cool is that SAS and SATA share the same cabling and interface! SAS is a superset of SATA, that adds SCSI's features (multiple devices per port, and so on) to the basic one-device-per-port SATA design. The nice thing is that you can use cheap SATA drives on a SAS setup! This should be good for RAID. Think of SAS as "SATA Plus".
Here's a quote from the link above:
"Serial Attached SCSI complements Serial ATA by adding device addressing, and offers higher reliability and data availability services, along with logical SCSI compatibility. It will continue to enhance these metrics as the specification evolves, including increased device support and better cabling distances. Serial ATA is targeted at cost-sensitive non-mission-critical server and storage environments. Most importantly, these are complementary technologies based on a universal interconnect, where Serial Attached SCSI customers can choose to deploy cost-effective Serial ATA in a Serial Attached SCSI environment."
iSCSI will be used in a SAN environment. This is only between computers and storage devices, and not betwen computers and the outside world. I think you're confusing SAN with LAN.
It's like how SCSI is set up today on a single computer: there's really no way to get access to the SCSI bus without first gaining access to the host computer. The LAN and the SCSI bus are two entirely different things, separated by the host computer.
When iSCSI is used, this separation should be preserved. The network that is set up for iSCSI, your SAN, should be kept separate from your main LAN. Think of it as a private network that is visible only from your file servers that have a need to access storage devices directly.
Think of a SAN as equivalent to your IDE or SCSI cable. A SAN network typically uses a block-based protocol, that will read and write individual disk sectors without regards to filesystems, access control, and so on. This is designed for maximum speed, not security. It is the job of the file server to translate this into file-based access for outside clients, and enforce the appropriate file permissions.
And yes, you should definitely have good security on your file servers....
http://www.adaptec.com/worldwide/common/index.h
iSCSI is useful as an interconnect in a SAN environment. The storage devices exist as their own node on the network, independently of the computers they are attached to. This is good for reliability (can replace the disk independently of the computer if it fails, and vice versa), configuration flexibility, and many other useful things.
iSCSI is nice because it uses standards that are well understood (Ethernet, TCP/IP) instead of custom networks like Fibre Channel. This should make SAN networks cheaper and more common, as well as providing an easy way to bridge a SAN network over the Internet (firewalled and encrypted, of course).
The only difference between a LAN and a SAN will be what you use it for!
Seems like a great idea to me! Hope it succeeds and becomes law. I have almost no telemarketing calls since I subscribed to the do-not-call list.
No, that's not true.
m
FM radio in the United States is always on odd frequencies: 88.1, 88.3, 88.5, etc. - 107.9.
Why do some stations have three letters? Because they have been grandfathered.
They existed before the FCC imposed the requirement to have four call letters.
http://www.oldradio.com/archives/general/3myst.ht
That pretty much is the definitive page!
I LOVE this idea!
When reading the recent Supreme Court decision, after the initial sorrow, I thought of this myself.
Congress has extended copyright in an effort to protect Steamboat Willie and a few other very profitable creations of the late 1920's. The vast majority of content created at that time is unfortunately decaying in vaults and warehouses, or forgotten completely. It can't be brought back alive in the public domain, because of the copyright extension.
The idea of a registry is great. People might gladly pay the tax to be listed in the registry, to make it easier to be found! When there is a desire to reuse an old creation during a new production, and pay money to that copyright holder, oftentimes the difficulty of finding the legitimate copyright holder is too great. Nobody wants to take the risk of having somebody crawl out of the woodwork after a production is completed and distributed worldwide, and sue for damages. So the use doesn't occur, which is a lose-lose situation. The idea of a registry fixes this! I can see the issuing of copyright numbers, similar to current patent numbers.
(C) #10,000,000 - 2003 Krellan
This compromise idea is great! It allows the public domain calendar to become unfrozen and finally start advancing past 1923. It protects Disney's big moneymakers. And it generates some extra revenue too!
The minute details would still need to be ironed out. What exactly constitutes a copyrighted work? If I create an album of music, do I have to pay the tax on each individual song, and/or on the album as a whole? If I write a software package, does each program, module, etc. need its own separate copyright registration?
Rolling all the way back to 50-year expiration would be too much to realistically expect now, I think. I support going back 80 years. This between the pre-SBCTEA and SBCTEA time periods. And this is exactly where the public domain calendar is currently stalled at (1923), so it makes sense to start here. There would be no sudden rush to register works in danger of immediately expiring.
Copyright law is different for individuals vs. companies, and this might need to be sorted out before a registry can be created. The "death plus X years" rule might need to be standardized and shortened to just "X years". Otherwise it will be a source of confusion: would works revert to their individual creators after the corporate copyright time expires, and if so, who gets the copyright when there are multiple people involved?
I hope the copyright tax is fair: not insignificant, but also not painful to an average individual person. A fee of $50 to $100 per work seems appropriate. It might be a lot of paperwork to assess this annually. I would much prefer the idea of assessing it every 5 years. As others have suggested, this would make it too easy to simply lock up content forever, so I also support increasing this over time. Mathematically doubling, as some have suggested, would quickly get ridiculous. As a compromise, a simple progression: $50 for the first 5 years, $100 for the next 5 years, then $150, $200, $250, and so on. If this outpaces inflation, it will provide an incentive for some people to simply drop it and let their work enter the public domain.
I am going to write my representatives. I hope that one of them is brave enough to introduce a bill!
http://pciids.sourceforge.net/
This site has another PCI device/vendor ID database.
Better save it while you can! There are download links available to get the entire table. Since the PCI-SIG has crushed the old yourvote.com site, there's no telling how long they will let this other site remain up, since it has similar content.
You might have the file already!
Download the latest version anyway, so your distribution is up to date. This file provides the human-readable names for tools such as lspci.
They've been doing this since RealPlayer 8.
See the rant from the last time this appeared on Slashdot, roughly August 2001, and my embellishments to it. I added a lengthy 12-step process for installing RealPlayer that is the best that can be done for disabling spam/spyware given the few options they give you:
http://www.krellan.com/rant/real.html
Also look at this funny picture that someone anonymously posted long ago, when a frustrated user decorated Real's building! If anyone knows the original source, I'd love to know it.
http://www.krellan.com/rant/real-buffering.jpg
In case Cedar Point's servers are going for a ride, here is more information:
:)
Stats
http://www.rcdb.com/installationdetail1896.htm
Press Release
http://www.rcdb.com/document82.htm
Pictures
http://www.rcdb.com/installationgallery1896.htm
Now, go slashdot rcdb instead.
Combining things from a snake and a chicken....
Am I the only one who thought of a basilisk?
I would be interested in a standalone box (no PC connection or software required) that converts HDTV to VGA. It would output to any ordinary PC monitor that accepts VGA. Many people have extra monitors lying around and it would be very cost effective to simply convert these into HDTV sets instead of buying new HDTV gear.
This ideal box would have:
* Antenna input, for the raw signal from the antenna
* HDTV tuner, with selectable channel (including selectable feed if channel is multiplexed)
* VGA output, to an ordinary PC monitor
* Audio output, with standard RCA jacks (or optional digital jacks) for sound
* Downscaler, to downgrade to a lower resolution in case the VGA monitor does not support a given resolution (the VESA DDC standard would be used to query the VGA monitor and detect what resolutions it supports, without needing user configuration)
* Optional remote control for the HDTV tuner
Simple, cost effective, does not require purchase of a monstrously huge and expensive set in order to watch HDTV, and does not involve the complication and setup hassles of a PC.
Does such a box exist? I would love to buy one.
The 4 steps when the server finishes sending data and closes the connection, from the article:
Client Server
<-- FIN
ACK -->
FIN -->
<-- ACK
When the server has no more data, it sends FIN.
The server should not be allowed to send more data after the FIN! This is a violation of the TCP spec. Otherwise, how would clients truly know whether or not the server had more data to send?
TCP does support something called "half close". It is possible to indicate that you have no more data to send, but that you are still willing to receive data. This is why both sides must send FIN, in order to cleanly close the connection. If one side sends FIN but the other doesn't, the connection remains open, but data can only flow in one direction (sending from the side that did not send the FIN). This is useful for cleanly shutting down connections and making sure that both sides receive all the data they were expecting.
In the example from the article, when the client receives a FIN but does not send a FIN of its own, this is legal: the TCP connection now is one way, and data can only be sent from the client to the server. The server is not allowed to send more data. So, if IIS is doing this, it is breaking the spec. It is important to note that the client is doing nothing wrong in this case.
Yes, that's exactly the bad decision that was made back then. Sectors are numbered starting with 1, but cylinders and heads are numbered starting with 0! Bizarre.
If it's truly a bug in Linux itself, instead of a bug in dd, then it should be even easier to fix. I hope this gets fixed in 2.5!
I read the NIST document and noticed they mentioned a limitation of dd.
When copying, dd only copies entire blocks. If there is an incomplete block of information remaining at the end of the disk, for example, dd will not copy that last block at all.
Since dd defaults to a block size of 1024 bytes, and PC hard drives use a sector size of 512 bytes, this could happen. In this case, dd will not copy the final sector of the hard disk, as it is an incomplete block.
Because of a stupid decision made decades ago, traditional PC hard disk addressing uses 63 sectors per track, not 64. Therefore, odd total numbers of sectors are common. Modern addressing does away with CHS and just numbers all sectors from 0 to the end of the disk (many millions, in most cases). Still, because of the legacy of having 63 sectors per track, many disks have an odd total number of sectors.
It would be nice if dd had an option to correctly copy a partial block at the end of the source. If there is an incomplete block, it should simply copy one byte at a time until there are no more bytes to copy.
This would be easy to add to dd. Has it been done already? If so, it should be documented. Making it the default behaviour might break existing applications, so have it as an option that is highly recommended.
Read the above post more carefully. The spammer was successful in spoofing the IP address of a TCP session, because he controlled both the dialup account and the high-speed account.
SYN from the dialup account.
SYN+ACK from the helpless email server back to the dialup account. Dialup account now has observed both sequence numbers.
ACK from the dialup account, and the SMTP transaction begins.
As sending mail consists mostly of uploading, upload packets to the server are forged from the high-speed account to the server. The dialup account only needs to receive the ACK for the sent data, and the SMTP responses from the server. The spammer uses both the dialup and the high-speed accounts in tandem to keep the connection alive, in effect intentionally hijacking his own TCP connection.
Very clever! The spammer must have had some help in setting up a scheme like this. I don't think he'd be smart enough to write the software on his own.
Another use of atomic checkins is checking in more than one file at a time, especially when checking in two files whose changes depend on each other. In my experience at several CVS shops, the build sometimes breaks simply because of unfortunate timing: checking out the tree while someone else is in the middle of checking in a series of files. Most shops deal with this manually, by having certain rules, such as no checkins allowed at all during a certain hour of the night.
If there was a way in CVS to begin a transaction, then do multiple checkins, then commit/rollback that transaction atomically, that would be wonderful. It would be impossible for one person to check out someone else's partial checkin.
If Subversion is getting this feature, or even has this already, it will be one of the best "selling points" to replace CVS!
True. This URL was the first mentioned on Bugtraq when this exploit was announced.
http://wwx.dino-soft.org/auto.html
(scrambled for your protection, as always: change wwx to www)
I tried it on two Windows 2000 machines.
One is patched up to date, the other is somewhat out of date. Both have SP3, though.
Results: The exploit failed on both machines.
When clicking on the link, four things pop up, each popping up on top of the previous:
So, I don't know the exact conditions that are needed to trigger this bug, but machines are not 100% vulnerable at this point.
The agreement on the surface seems reasonable and fair: 8% of gross income or 5% of non-bandwidth-related expenses, whichever is greater.
However, the retroactive minimum fees are killer!
It will cost a minimum of $8,500.00 for a long-lived webcasting station to legally get back on the air. A fee of $2,000.00/year for years 1999-2002, plus a prorated fee of $500.00 for 1998 (the DMCA did not take effect until October 1998). Many small time radio stations and hobbyist stations cannot afford this!
I'm glad the law gives college radio stations and other nonprofits extra time to work this out.
If stations five years ago had known about the killer retroactive fees that would be coming due now, very few of them would have continued webcasting after that fateful day in October 1998!
To me, the solution is to forgive the retroactive fees, in exchange for agreeing to pay the new fees for years 2003 and beyond.
It seems too many people distrust spam filters because of the chance of accidentally blocking an important legitimate message as if it were spam.
Many spam filters are strictly binary: a message is either spam, or not spam. This is not ideal, because "gray area" messages - between these two extremes - will likely not be sorted correctly.
I propose adding a new sort option to email clients.
Sort by Spam Probability
This would be an additional field that can be displayed in a message list, similiar to "To", "From", "Subject", and the like. Like the article, probabilities would range from 99% (almost certain spam) to 1% (most likely an innocent message). Notice that 100% accuracy either way is not claimed.
This way, the user can see up front the messages that are most likely not spam. The spam messages will be relegated to the bottom of the list, possibly colored to indicate their likelihood of being spam. If there is a message in the "gray area", it will most likely appear in the list between the legitimate messages and the spam, so the user will have a chance to see the message and make a decision, without the message being lost in the shuffle.
This would be a great feature. I hope this gets into Mozilla's mail client.
(BTW, another feature that would be great to see in mail clients would be datestamping of the actual time the message was downloaded. Many spammers, and innocent people with misconfigured clocks, send emails with wild dates that are not to be trusted. You can see this in yearly archives of GNU "mailman" mailing lists! Datestamping emails as they are downloaded will also keep mailboxes in order when sorted by date, as newly arrived messages will always be at the bottom, instead of being scattered throughout the inbox. But sorting by spam probability will probably become more popular than sorting by date....)
I believe the Linux kernel should not be called 3.0 until it is 64-bit through and through.
The difference between 1.x and 2.x was a major architectural change: multiprocessor capability and portability to different platforms. The difference of 3.x should be equally as large: widening of all interfaces and data structures that are currently reaching their limits.
This includes 64-bit memory access, 64-bit file size access, 64-bit block counts on filesystems, and so on. Important external interfaces such as networking and filesystems must also be widened. A fully complete and robust IPv6 stack is a must: something that isn't quite there yet, but is getting close.
Essentially all fields in stat() require widening! Major and minor device numbers desperately need more room. Inode numbers and file size 64-bit, of course. Timestamps need to fix the Y2038 problem: 64-bit, possibly with added precision as well (to guarantee each file can be unambiguously sorted by time even on fast systems with such applications as parallel make). Security needs to be more fine grained (full ACL support). 32-bit UID and GID numbers. And finally, the filename itself needs to have full Unicode support without loss of field width (255 Unicode characters should be accepted). The output of the ls(1) command is a call to action: essentially every field there is in need of widening!
The main difference should be in the defaults: currently, standard stat() file limits and IPv4 are the defaults, and programs must go out of their way to request larger sizes (O_LARGEFILE) and IPv6. The programming model should be changed to provide programs with the widened resources as standard. This will take a long time, and is a gradual evolution, so there is a definite need for 2.6 and possibly 2.8 as transitional steps. The widening of these critical system resources is probably the main thing keeping Linux from large commercial UNIX installations!
Wow, you've been censored!
I viewed the same link as you, and got these top 3 results:
antiw*r.com "leave china alone"
english.peopledaily.com.cn "foreign f***n g**g activists asked to leave"
hyperm*rt.net "yankees leave china alone"
And then some news articles about the North K*reans seeking asylum in China then moving to South K*rea.
I starred out things above so hopefully the Great Firewall of China won't block this post and you can read it.
I have a friend in China and we often ICQ each other to test the firewall and verify things he's researching, and we've ran into several surprising differences....
Comparing two copies and averaging out the watermark is easy... provided you can crack the encryption. Once you do that, it's game over, and the studio has a lot more than the watermark to worry about.
I hope they start the clock running when you first decide to view the movie, not when it's downloaded. I can see having a period like 30 days in which the movie file would be valid on your system, ready to be viewed at any time, at which point the 24-hour timer would start. This solves the problem of not having enough time at the moment, which often happens when renting movies from the video store.
Want to watch the movie more than a few times? Buy it on DVD at full price, for unrestricted viewing (region codes notwithstanding). In my experience, there are very few movies that are worth watching more than once, and those few are keepers!