Slashdot Mirror

I agree with the majority of your post, except for the emphasis on IF:
This is very much field-dependent. Especially in computer science, IF is not a meaningful metric, because it only considers journal publications. About a third of the CS "journals" are not actually journals (i.e., the Springer Lecture Notes in Computer Science series, which contains proceedings or extended papers from conferences), and a relatively small part of the remaining set is published by Elsevier (which is mostly junk with a few extremely good papers).

Beyond that, journals are basically an archivial tool. Papers in journals are those you use to support an argument or give to students as an introduction to a field. The real work is always in conferences - especially the higher tier ones such as the USENIX security conference, Crypto/Eurocrypt, IEEE Security & Privacy, and so on and so forth (see here and here for some stats). These conferences are generally not trivial to get in (10-20% acceptance rate) and are publishing all the work you'll be expected to cite in your next paper.

On the other hand, CS is in the unique position where there are only three publishers that matter (not counting usenix): the IEEE, the ACM and Springer. Although these cost significant money, they are so kind as to allow authors to publish an author version on their website - which nearly every author has, and which google scholar indexes. Thus it is reasonably easy for us to know which conferences and journals are worth publishing in. You don't need your supervisor to know that Globecom is a load of shit, with an acceptance rate sometimes reaching over 40%.

The specific case (covered heavily - check Techdirt for one) in question has actually brought in a much larger problem to light. How should students treat code written as part of assignments or as part of their course-work in terms of licensing? Is there a precedent for licensing? Most research activities conducted by universities have already adopted licensing framework. Here's an example. There has been debate whether such licensing should be free. Just check Medical Research and you can open Pandora's box. One more example is Singapore's A-Star which is more of a group focused on preparing research for industry adoption including licensing and legal usage terms.

How about code released in books on Data Structures, Algorithms, Fundamental C programming? To my knowledge (do correct me if I am wrong), the code is usually licensed under the same copyright notice as the book itself. In some cases, the author changes this licensing and makes it available. One example is "Numerical Recipes in C" where the licensing terms of the code from the author(s) of the book is explicit and can be found on a google search.

When it comes to university assignments, it is no news that the same template (if not the same course material itself) tends to get recirculated over a periodic basis. In some cases this period is annual and in others, the frequency is different. The debate raised is ages old. For most data structure or standard assignments of programming, you could find most of the code online. You could use this as a starting point or choose to write your own and learn your fundamentals. That's up to the student and the professor who is teaching and grading.

There is some truth in the statement (IMHO) that the Academia is shielded from the real commercial world. It works positive in some cases and is counterproductive in fields like Engineering (not Theoretical Computer Science.) In this specific case, if the University were to read all the fine print they have on students sharing course material (for which they pay for) and lecture notes and assignments, they would find the right solution. Bringing this (issue between a student and the professor) out to Open forums seems more of a publicity stunt that is going to get someone infamous for some and noticeable for a few others.

Focusing on the larger issue, a Varsity must be clear on how course-work and assignments from the students will be licensed and treated. They already have set legal precedents for most research work (which in some cases is funded by commercial bodies.) Hopefully this issue raises a flag and lets varsities understand and embrace Open Source, encourage students to use it particularly in programming assignments. At the very least they should at least reserve procedures to let a student obtain due permission for displaying his/her works online under appropriate licensing. In the absence of a precedent and clear guidelines, such confusion and unnecessary nerve wracking experiences between a Professor and a Student are more likely to surface. I hope not.

I don't think this is garbage research -- I was involved in the USENIX Security'07 study someone else mentioned in this thread (http://s3g.i2r.a-star.edu.sg/papers/metrowifi-usenixsec07.pdf). That one was peer-reviewed at a well-respected conference, backed with a proof-of-concept worm (called Wildfire/A -- for both XP and Vista) and reaches somewhat similar conclusions. I think the main difference is that we looked at infections of computers behind APs rather than the APs themselves -- after all, you're more likely to get vulnerabilities there than on the APs. Another difference is that our study was performed in 2006, so the Indiana Univ. paper may involve more up-to-date wifi maps. Of course, more widespread use of WPA mitigates a large part of this and other wifi threats, but as we argue in our study does not completely eliminate them. FWIW, we are releasing a few animations of the simulated worm spread on youtube.. links are posted on http://s3g.i2r.a-star.edu.sg/proj/wildfire/

I don't think this is garbage research -- I was involved in the USENIX Security'07 study someone else mentioned in this thread (http://s3g.i2r.a-star.edu.sg/papers/metrowifi-usenixsec07.pdf). That one was peer-reviewed at a well-respected conference, backed with a proof-of-concept worm (called Wildfire/A -- for both XP and Vista) and reaches somewhat similar conclusions. I think the main difference is that we looked at infections of computers behind APs rather than the APs themselves -- after all, you're more likely to get vulnerabilities there than on the APs. Another difference is that our study was performed in 2006, so the Indiana Univ. paper may involve more up-to-date wifi maps. Of course, more widespread use of WPA mitigates a large part of this and other wifi threats, but as we argue in our study does not completely eliminate them. FWIW, we are releasing a few animations of the simulated worm spread on youtube.. links are posted on http://s3g.i2r.a-star.edu.sg/proj/wildfire/

Similar work has already been published at Usenix Security. http://www.usenix.org/events/sec07/tech/akritidis.html
Full paper is available at one of the authors' website. http://s3g.i2r.a-star.edu.sg/papers/metrowifi-usenixsec07.pdf

Windows lets you do it with a GUI too, though not per user. Find remapkey.exe.

Or you can find one of the registry files that will do it.

Or you can get one of the third party tools (there are others) that do it.

I'm surprised to see nobody has yet mentioned HyperSCSI, which is:
- opensource
- based on raw ethernet (supposedly faster than iSCSI or other TCP/IP-based schemes)
- has a Win2K client

Check it out, I've tested and used it since about a year and it works quite well!
--
Nicson

from the website:

HyperSCSI is a networking protocol designed for the transmission of SCSI commands and data across a network. To put this in "ordinary" terms, it can allow one to connect to and use SCSI and SCSI-based devices (like IDE, USB, Fibre Channel) over a network as if it was directly attached locally.

http://nst.dsi.a-star.edu.sg/mcsa/hyperscsi/

They would really need to sweeten the pot to make this interesting. They need to be able to have a single appliance software stack that is capable of exporting filesystems over the network as well as block devices. If they added something on the SERVER end like HyperSCSI (or iSCSI, but HyperSCSI is faster/free), it would be more interesting, no?

• Saying "TCP/IP" does not normally mean TCP.. it means the entire protocol suite. Saying something runs "on tcp/ip" is ambiguous.
• "Raw ethernet" usually means "another layer 3 protocol"
• iSCSI uses TCP as a transport. iSCSI IETF Draft.

• HyperSCSI is a layer 3 protocol. HyperSCSI Spec
• HyperSCSI on ethernet uses a EtherType field of 0x889a.
• With iSCSI, you can route over an IP network to your devices.. you could have a storage subnet, for instance.
• We want storage to be as fast as possible, and generally it will be local, so HyperSCSI makes more sense. It's just a new way to build a SAN rather than using Fiberchannel... now we have gigabit ethernet, and so on.

HP's Graham Smith says:

"Without TCP/IP, it has no real error-recovery mechanism or guarantee that packets get delivered."

But that is wrong. There is error checking in the ethernet hardware and in the SCSI stack. It seems Smith needs to review the basic material, or should have at least read the introductory material. Perhaps the takeaway here is, managers should not be allowed to comment on technical material, or if they do, they should solicit advice from a practicing engineer first.

Smith also dumps on HyperSCSI's scalability, but as far as I can see, it scales exactly as well as any LAN, and for storage that's not bad at all. Besides, being 100% open source, implementing a repeater sitting on a routing box is entirely practical.

As far as Andre's comments go, the article should have disclosed that he peddles an iSCSI stack for a living. More power to him, I'm not criticizing his colorful comments or business scheme, just the journalist's failure to take note of this.

Now, my own opinion: I haven't tried HyperSCSI yet. I have it installed here and by rights I should have given it a thorough workout by now, but mea culpa. So little time, so much to do. Well I'll change that today.

From what I know so far: I like the idea of trimming away unnecessary layers. It's the kind of thing we do in Linux all the time. I like the fact that the whole stack is GPL. It doesn't bother me that disk drives themselves don't support the protocol and are unlikely to in the near future, because you have to put the disks in a box anyway, and that might as well be a Linux box presenting a HyperSCSI interface.

Personally, I think that HyperSCSI is going somewhere. So is iSCSI for that matter: the two protocols serve distinctly different target markets. iSCSI is where the money is because hardware vendors support it. HyperSCSI is where the joy of hacking is because it performs better and it's GPL. The thing is, they both present the same interface to the OS (SCSI) so they are interchangable. It's not an either/or situation at all.

You need to pay careful attention to any technique that increases performance without increasing cost.

The article does and abysmal job of covering this, but the homepage for HyperSCSI has a nice PDF presentation that covers just this topic. In short, it goes something like this: The SCSI protocols already provide error checking The HyperSCSI layer adds flow control and retransmits Ethernet provides certain other checks So, in total, you have the same reliabilty of iSCSI and FibreChannel with less overhead (i.e. significant overlapping of the protocols in terms of error detection/correction).

Most Web links seem rather heavy on the physics side, but this was good for me:

http://www.dsi.a-star.edu.sg/tracks/media/research /perpendicular.html

What about a watch that periodically samples biometric data from the skin beneath it?

There are wristwatches that sample glucose for monitoring diabetic's blood-sugar level, such as the GlucoWatch.

There are also devices for processing fluids in a microsystem, such as the MEMS's Biochip.

In the near future the wristwatch could eliminate the need for visible user-token authentication, or at least reduce its frequency. This would greatly increasing both the security of the system and its ease of use.

A subset of the SCSI-3 standard, also known as IEEE 1394, Firewire is a new high speed data exchange protocol developed at Apple. Occasionally it is referred to as "serial SCSI" because it is a serial protocol and conforms to SCSI standards as well.

They stated that in a fashion that is, at best, a bit confusing. This draft specification for the SCSI architectural model shows on page 10 a diagram showing that there are several interconnect layers for SCSI, including the classic parallel SCSI bus (SPI), and three count 'em three serial layers, namely Fibre Channel (FC-PH), FireWire ("IEEE 1394 High Performance Serial Bus"), and IBM SSA (SSA-PH), with each interconnect layer having a protocol used to implement SCSI on that layer.

Then there are the SCSI commands, which are mostly if not entirely independent of the interconnect layer and protocol. They can be sent over parallel SCSI, Fibre Channel+FCP, FireWire+SBP, SSA-PH+SSP, {pick your link layer}+IP+TCP+iSCSI, Ethernet+HyperSCSI, or the Serial ATA link layer+serial attached SCSI, and, apparently USB+some way of sending SCSI commands over USB. (There certainly don't seem to be many bit-serial links over which you can send SCSI commands and replies.... :-))

FireWire isn't "SCSI", it's an interconnect over which you can send SCSI commands and replies. It's also an interconnect over which you can send stuff that has nothing to do with SCSI, e.g. IP datagrams (we ignore here the possiblity of IP datagrams containing TCP segments that make up iSCSI PDUs :-)), just as Fibre Channel is an interconnect over which you can send SCSI commands and replies, as well as stuff that has nothing to do with SCSI, e.g. IP datagrams, and just as USB is an interconnect over which you can send SCSI commands and replies, as well as stuff that has nothing to do with SCSI, including network packets.

Try this:

hyperscsi