Thank you for finding this; I'd been trying to find any explanation of what they were actually offering. As for the 'on sale later this year' it sounds highly speculative. The only detail I can found out about the company they mention is that the company registration documents still show it as based in the University buildings, so it seems unlikely they've got anywhere near commercial production yet.
dg@major:~$ dd if=/dev/sr0 of=/dev/null bs=1024k dd: reading `/dev/sr0': Input/output error 580+1 records in 580+1 records out 608698368 bytes (609 MB) copied, 179.877 s, 3.4 MB/s
[32062.556698] sr 1:0:0:0: [sr0] Unhandled sense code [32062.556704] sr 1:0:0:0: [sr0] [32062.556707] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [32062.556710] sr 1:0:0:0: [sr0] [32062.556712] Sense Key : Medium Error [current] [32062.556717] sr 1:0:0:0: [sr0] [32062.556720] Add. Sense: Unrecovered read error [32062.556723] sr 1:0:0:0: [sr0] CDB: [32062.556725] Read(10): 28 00 00 04 89 00 00 00 30 00 [32062.556736] end_request: I/O error, dev sr0, sector 1188864 [32062.556742] Buffer I/O error on device sr0, logical block 297216 [32062.556748] Buffer I/O error on device sr0, logical block 297217 [32062.556756] Buffer I/O error on device sr0, logical block 297218 [32062.556758] Buffer I/O error on device sr0, logical block 297219 [32062.556761] Buffer I/O error on device sr0, logical block 297220 [32062.556764] Buffer I/O error on device sr0, logical block 297221 [32062.556766] Buffer I/O error on device sr0, logical block 297222 [32062.556769] Buffer I/O error on device sr0, logical block 297223 [32062.556771] Buffer I/O error on device sr0, logical block 297224 [32062.556774] Buffer I/O error on device sr0, logical block 297225 [32069.527607] sr 1:0:0:0: [sr0] Unhandled sense code [32069.527613] sr 1:0:0:0: [sr0] [32069.527616] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [32069.527619] sr 1:0:0:0: [sr0] [32069.527621] Sense Key : Medium Error [current] [32069.527626] sr 1:0:0:0: [sr0] [32069.527629] Add. Sense: Unrecovered read error [32069.527632] sr 1:0:0:0: [sr0] CDB: [32069.527634] Read(10): 28 00 00 04 89 00 00 00 02 00 [32069.527646] end_request: I/O error, dev sr0, sector 1188864 [32069.527650] quiet_error: 38 callbacks suppressed [32069.527653] Buffer I/O error on device sr0, logical block 297216 [32069.527658] Buffer I/O error on device sr0, logical block 297217 [32076.499895] sr 1:0:0:0: [sr0] Unhandled sense code [32076.499901] sr 1:0:0:0: [sr0] [32076.499904] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [32076.499907] sr 1:0:0:0: [sr0] [32076.499909] Sense Key : Medium Error [current] [32076.499914] sr 1:0:0:0: [sr0] [32076.499917] Add. Sense: Unrecovered read error [32076.499920] sr 1:0:0:0: [sr0] CDB: [32076.499922] Read(10): 28 00 00 04 89 00 00 00 02 00 [32076.499934] end_request: I/O error, dev sr0, sector 1188864 [32076.499938] Buffer I/O error on device sr0, logical block 297216 [32076.499943] Buffer I/O error on device sr0, logical block 297217
so I'd say it looks like it's found at least 2 bad logical blocks on the CD, and I suspect it eventually retried it OK, because a df on the mounted CD shows 581M which MB v MiB is equivalent to the 609 figure that came out of the dd - so I reckon it eventually (after a try or two) read the lot.
Looks ok:-) That's been stored on a dusty shelf in my room for the last ~17 years (in jewel case) having said that it was a good quality kodak blank, and your mileage may vary.
IMHO store multiple copies written on multiple vendors media written on multiple drives; use a few types of storage (CD, USB-flash from a good vendor), and something like laser printed (not-ink jet) QR code on good paper; I'd wrap each separately (hmm what in?)
Oh, and in 25 years come back and tell us how much data is visible.
The NSA did SELinux (for Linux...) so I don't think it's unreasonable to think they might have helped MS on security issues without doing anything nasty.
'A: LINA is dual licensed. For non-commercial users, LINA is available under the GNU General Public License, Version 2.
If you wish to use it commercially, please contact us to find out more about the LINA commercial license.'
Erm I'm sorry?! You can't stop someone using a GPL licensed program for commercial use. Do they mean to say that if you want to sell it or do none-free changes then they will sell you a non-GPL license?
I'd like to know if someone was to spend say $100B more on the fusion development projects whether we would know if they worked any sooner. If it works it would seem to be the solution to the global warming problem without us all having to work in the dark. Would extra money speed up the research?
The major problem I hit seems to be related to software RAID where the boot is hanging for 6 minutes with a black screen with no diags. (filed as bug 68888). This seems to be related to the change to UUID's (which IMHO is horrid even more so than RHELs use of LABELs - I can remember that my root device was hda1 or has a label of / but anyone who can remember a UUID of 9d3f7a30-72ef-4d24-947c-3efc6bd9e6b6 should get a job as a memory man or IPV6 coordinator).
However, with that sorted I haven't hit anything else; there were the normal couple of dependency problems during the dist-upgrade relating to other stuff I'd installed.
My worry is with the statement 'information shared is never lost in free software' - I think there is a lot that is discarded under the 'oh that's something the distro did' when it might reveal real issues. Also, there are a lot of places reports go to among all the distros; I don't believe they are all finding there way back into places other people can find them.
As for wanting to use newer kernels I have three reasons:
1) Because modern hardware often needs modern kernels (e.g. SATA controllers on modern servers - a lot of them no longer work in PATA compatibility mode).
2) Because of the better IO scheduling on 2.6.x
3) To see if older bugs are fixed; for example I had a driver bug reported against 2.6.x that has happened on and off for ages; the maintainer asked me to see if it still happened on 2.6.16 - but this is a production server, I daren't upgrade to 2.6.16 because of stability issues I've seen on other systems. So this bug remains unfixed/unknown.
Yes - I have some sympathy for that position; and I'd happily run mainline kernels if they were stable - but like many people, I've got no choice except to use the distro kernels.
But the effect is that real problems that people are finding in distro kernels go unfixed because the mainstream guys can't look at them.
The best solution would be for the mainline kernel to get stable and there to be very few differences to distro kernels - but my point is that in the divided world that currently exists real problems aren't getting reported that are actually not due to distro patches.
My experience is that stability is dropping, even on modern hardware. You can no longer take the latest '2.6' stable kernel and expect it to keep your server running stably.
Now, you can take a Redhat or SuSE packaged kernel and find those are pretty stable. But there is a problem; if you report a bug in a Redhat/SuSE kernel on the lk.ml you get a 'that's Redhat/SuSE problem - speak to them'.
As the 2.6.x stable tree becomes less stable, less people use them on production servers and instead use packaged kernels. As less people use them, they get tested less - and less bugs are actually reported for them.
It is also not just a case of old hardware; in the last few kernels I've had leaks that make a simple firewall die repeatedly after a few months, I've got a machine with a slow RAM kernel leak that makes a simple DHCP server fall over every few months, and I've had a 2.6.1x kernel that couldn't run an NFS server for 24 hours without falling over.
Hi,
I've been looking at the free calendaring disaster for a while now - and it is; there are perhaps 5-10 different packages, none of which interoperate; some very nice clients that only talk to really crap servers and some very nice servers with poor clients.
Lets get some convergence here - please can we actually lock the
Zimbra, Open Exchange, Sunbird, Open Groupware, Kolab (I must have missed some....) guys in a cave without food for a while until they actually agree to work together? For a concession I'll let caffeinated beverages in and a few computers with a copy of all known calendaring specs.
(please toss in a couple of guys with MS programming experience so we can get Outlook to talk to the servers).
I remember reading a long time (at least 10 years, perhaps 20?) ago about direct stimulation of the visual cortex; now at the time they were just doing a few blobs intended to help the blind.
This looks like it is moving a bit further up the chain a bit which should be interesting; in the end it is just vision however.
Nod, I've just finished reading this (something that I should have done long ago).
It is filled with lots of examples of this type of thing (and other bizarre parasitic cases) and talks a lot about the reasons for it.
In particular his idea of the 'Extended phenotype' where the influence of a gene is on the whole of the environment not just the 'vehicle' that carries and reproduces the gene.
Of course Gentoos version will be a kit car; it will give you 3 options for the level you want to start with:
* Preassembled body parts (doors, engine etc) - for the wimps.
* Precut, cast metal ready to assemble.
* Metal ore for the real hard cases.
Many of the online systems promise many things about encryption; I guess they all promise stuff is encrypted over the wire, and I guess most also state that stuff is encrypted on their storage servers.
But with what keys - and where are those stored?
I'm aware of at least one (very large!) online storage company who has a small note in their docs saying that the keys are stored 'in escrow' with them - i.e. everything is nice and safely encrypted but they have the keys to decrypt them! They're docs also say how that key can get revealed to lawyers in some cases, and I think to end users who forget their keys.
What is needed here (but would of course be difficult to do - both politically and technically) is to make laws at the EU or US level that ban their companies from participating in censorship - probably impossible to get through though
Yep - exactly the same thing; Dell with pair of maxtors, one fell out of the RAID mirror and while rebuilding the other one went.
Another Dell server with maxtor drives lost its drive after 2 months.
One odd thing; in the first one SMART showed the drive was fine - passed every test, had no remapped sectors - but still had a log entry of uncorrectable error (seen by both the OS and in the SMART logs). WTF!
Oh - when I was talking about dodgy I didn't mean swearing (I don't care about those); I meant things about for example:
1) Other employees
2) Your boss
3) Your customers
So the really important thing is to really look through your code first - you need to:
1) Check it is all really your code - you didn't buy any in 5 years ago? If you have a source code control system then actually being able to trace your code is great.
2) Read the comments - ok, so lots of closed source contains rather dodgy comments that you might not want to be public.
3) Check that releasing it wouldn't be revealing any information you got under NDA from any of your suppliers/partners.
We caught a xerox network laser printer trying to send mail, by itself back to xerox; it tried three different outgoing smtp servers that fortunately our gateway blocked.
I don't know what was in those mails - but a google search revealed an article about a large data mining system based on Oracle; I think the main intent was to detect reasons for early failure - but who knows what happened to the data.
Slashdot Mirror
Thank you for finding this; I'd been trying to find any explanation of what they were actually offering.
As for the 'on sale later this year' it sounds highly speculative. The only detail I can found out
about the company they mention is that the company registration documents still show it as
based in the University buildings, so it seems unlikely they've got anywhere near commercial
production yet.
Well, not too bad,
dg@major:~$ dd if=/dev/sr0 of=/dev/null bs=1024k
dd: reading `/dev/sr0': Input/output error
580+1 records in
580+1 records out
608698368 bytes (609 MB) copied, 179.877 s, 3.4 MB/s
[32062.556698] sr 1:0:0:0: [sr0] Unhandled sense code
[32062.556704] sr 1:0:0:0: [sr0]
[32062.556707] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[32062.556710] sr 1:0:0:0: [sr0]
[32062.556712] Sense Key : Medium Error [current]
[32062.556717] sr 1:0:0:0: [sr0]
[32062.556720] Add. Sense: Unrecovered read error
[32062.556723] sr 1:0:0:0: [sr0] CDB:
[32062.556725] Read(10): 28 00 00 04 89 00 00 00 30 00
[32062.556736] end_request: I/O error, dev sr0, sector 1188864
[32062.556742] Buffer I/O error on device sr0, logical block 297216
[32062.556748] Buffer I/O error on device sr0, logical block 297217
[32062.556756] Buffer I/O error on device sr0, logical block 297218
[32062.556758] Buffer I/O error on device sr0, logical block 297219
[32062.556761] Buffer I/O error on device sr0, logical block 297220
[32062.556764] Buffer I/O error on device sr0, logical block 297221
[32062.556766] Buffer I/O error on device sr0, logical block 297222
[32062.556769] Buffer I/O error on device sr0, logical block 297223
[32062.556771] Buffer I/O error on device sr0, logical block 297224
[32062.556774] Buffer I/O error on device sr0, logical block 297225
[32069.527607] sr 1:0:0:0: [sr0] Unhandled sense code
[32069.527613] sr 1:0:0:0: [sr0]
[32069.527616] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[32069.527619] sr 1:0:0:0: [sr0]
[32069.527621] Sense Key : Medium Error [current]
[32069.527626] sr 1:0:0:0: [sr0]
[32069.527629] Add. Sense: Unrecovered read error
[32069.527632] sr 1:0:0:0: [sr0] CDB:
[32069.527634] Read(10): 28 00 00 04 89 00 00 00 02 00
[32069.527646] end_request: I/O error, dev sr0, sector 1188864
[32069.527650] quiet_error: 38 callbacks suppressed
[32069.527653] Buffer I/O error on device sr0, logical block 297216
[32069.527658] Buffer I/O error on device sr0, logical block 297217
[32076.499895] sr 1:0:0:0: [sr0] Unhandled sense code
[32076.499901] sr 1:0:0:0: [sr0]
[32076.499904] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[32076.499907] sr 1:0:0:0: [sr0]
[32076.499909] Sense Key : Medium Error [current]
[32076.499914] sr 1:0:0:0: [sr0]
[32076.499917] Add. Sense: Unrecovered read error
[32076.499920] sr 1:0:0:0: [sr0] CDB:
[32076.499922] Read(10): 28 00 00 04 89 00 00 00 02 00
[32076.499934] end_request: I/O error, dev sr0, sector 1188864
[32076.499938] Buffer I/O error on device sr0, logical block 297216
[32076.499943] Buffer I/O error on device sr0, logical block 297217
so I'd say it looks like it's found at least 2 bad logical blocks on the CD, and I suspect it eventually
retried it OK, because a df on the mounted CD shows 581M which MB v MiB is equivalent to the 609 figure
that came out of the dd - so I reckon it eventually (after a try or two) read the lot.
Dave
/me takes dusty 1995 Linux CD-R that we wrote off shelf, and puts it in:
dg@major:/media/CDROM$ ls -l
total 575
dr-xr-sr-x 3 dg dg 69632 Jul 12 1995 bitmaps
dr-xr-sr-x 2 dg dg 2048 Jul 5 1995 ddd
-r--r--r-- 1 dg dg 441397 Jul 18 1995 DirList.180795
dr-xr-sr-x 13 dg dg 6144 Jul 18 1995 documentation
dr-xr-sr-x 2 dg dg 4096 Jul 10 1995 ELF-GCC
dr-xr-sr-x 10 dg dg 2048 Jul 11 1995 emulators
dr-xr-sr-x 2 dg dg 2048 Jul 5 1995 fvwm
dr-xr-sr-x 2 dg dg 18432 Jul 10 1995 gnu
dr-xr-sr-x 11 dg dg 2048 Jul 10 1995 kernel-source
dr-xr-sr-x 3 dg dg 2048 Jul 11 1995 languages
dr-xr-sr-x 2 dg dg 6144 Jul 18 1995 leftovers
-r--r-xr-- 1 dg dg 99 Jul 13 1995 Leftovers_dir_list
dr-xr-sr-x 7 dg dg 4096 Jul 12 1995 logos
dr-xr-sr-x 2 dg dg 2048 Jul 11 1995 Networking
dr-xr-sr-x 6 dg dg 2048 Jul 18 1995 pgp
dr-xr-sr-x 2 dg dg 2048 Jul 11 1995 Printing
-r--r-xr-- 1 dg dg 5814 Jul 18 1995 README.html
dr-xr-sr-x 11 dg dg 4096 Jul 10 1995 slakware
dr-xr-sr-x 4 dg dg 2048 Jul 18 1995 sunsite.unc.edu
-r--r--r-- 1 dg dg 1015 Jul 18 1995 TRANS.TBL
dr-xr-sr-x 5 dg dg 2048 Jul 10 1995 www
dr-xr-sr-x 3 dg dg 4096 Jul 11 1995 X
dr-xr-sr-x 2 dg dg 2048 Jul 5 1995 xemacs
Looks ok :-) That's been stored on a dusty shelf in my room for the last ~17 years (in jewel
case) having said that it was a good quality kodak blank, and your mileage may vary.
IMHO store multiple copies written on multiple vendors media written on multiple drives;
use a few types of storage (CD, USB-flash from a good vendor), and something like
laser printed (not-ink jet) QR code on good paper; I'd wrap each separately (hmm what in?)
Oh, and in 25 years come back and tell us how much data is visible.
It's interesting them doing at-rest-encryption - now I wonder where the keys are stored and who has access to them?
Sounds like someone should send them a bill for cleaning it up.
The NSA did SELinux (for Linux...) so I don't think it's unreasonable to think they might have helped MS on security issues without doing anything nasty.
From their FAQ:
'A: LINA is dual licensed. For non-commercial users, LINA is available under the GNU General Public License, Version 2.
If you wish to use it commercially, please contact us to find out more about the LINA commercial license.'
Erm I'm sorry?! You can't stop someone using a GPL licensed program for commercial use.
Do they mean to say that if you want to sell it or do none-free changes then they will sell
you a non-GPL license?
I'd like to know if someone was to spend say $100B more on the fusion development projects whether we would know if they worked
any sooner. If it works it would seem to be the solution to the global warming problem without us all having to work in the dark.
Would extra money speed up the research?
The major problem I hit seems to be related to software RAID where the boot is hanging for 6 minutes with a black
screen with no diags. (filed as bug 68888).
This seems to be related to the change to UUID's (which IMHO is horrid even more so than RHELs use of LABELs - I can
remember that my root device was hda1 or has a label of / but anyone who can remember a UUID
of 9d3f7a30-72ef-4d24-947c-3efc6bd9e6b6 should get a job as a memory man or IPV6 coordinator).
However, with that sorted I haven't hit anything else; there were the normal couple of dependency problems
during the dist-upgrade relating to other stuff I'd installed.
My worry is with the statement 'information shared is never lost in free software' - I think there is a lot
that is discarded under the 'oh that's something the distro did' when it might reveal real issues.
Also, there are a lot of places reports go to among all the distros; I don't believe they are all finding there
way back into places other people can find them.
As for wanting to use newer kernels I have three reasons:
1) Because modern hardware often needs modern kernels (e.g. SATA controllers on modern servers - a lot of them no longer work in PATA compatibility mode).
2) Because of the better IO scheduling on 2.6.x
3) To see if older bugs are fixed; for example I had a driver bug reported against 2.6.x that has happened on and off for ages; the maintainer asked me to see if it still happened on 2.6.16 - but this is a production server, I daren't upgrade to 2.6.16 because of stability issues I've seen on other systems. So this bug remains unfixed/unknown.
Yes - I have some sympathy for that position; and I'd happily run mainline kernels if they were stable - but like many people, I've got no choice except to use the distro kernels.
But the effect is that real problems that people are finding in distro kernels go unfixed because the mainstream guys can't look at them.
The best solution would be for the mainline kernel to get stable and there to be very few differences to distro kernels - but my point is that in the divided world that currently exists real problems aren't getting reported that are actually not due to distro patches.
My experience is that stability is dropping, even on modern hardware. You can no longer take the latest '2.6' stable kernel and expect it to keep your server running stably.
Now, you can take a Redhat or SuSE packaged kernel and find those are pretty stable.
But there is a problem; if you report a bug in a Redhat/SuSE kernel on the lk.ml you get a
'that's Redhat/SuSE problem - speak to them'.
As the 2.6.x stable tree becomes less stable, less people use them on production servers and instead
use packaged kernels. As less people use them, they get tested less - and less bugs are actually reported for them.
It is also not just a case of old hardware; in the last few kernels I've had leaks that make
a simple firewall die repeatedly after a few months, I've got a machine with a slow RAM kernel leak
that makes a simple DHCP server fall over every few months, and I've had a 2.6.1x kernel that couldn't
run an NFS server for 24 hours without falling over.
It ain't nice - but these are my experiences.
Dave
Hi,
I've been looking at the free calendaring disaster for a while now - and it is; there are
perhaps 5-10 different packages, none of which interoperate; some very nice clients that
only talk to really crap servers and some very nice servers with poor clients.
Lets get some convergence here - please can we actually lock the
Zimbra, Open Exchange, Sunbird, Open Groupware, Kolab
(I must have missed some....)
guys in a cave without food for a while until they actually agree to work together?
For a concession I'll let caffeinated beverages in and a few computers with a copy
of all known calendaring specs.
(please toss in a couple of guys with MS programming experience so we can get Outlook
to talk to the servers).
I remember reading a long time (at least 10 years, perhaps 20?) ago about direct stimulation of the visual cortex;
now at the time they were just doing a few blobs intended to help the blind.
This looks like it is moving a bit further up the chain a bit which should be interesting;
in the end it is just vision however.
That 'SIOX' object selection stuff looks really really cute; you have to wonder if it would come in useful for machine vision/AI as well.
Anyway - good luck to the GIMP guys - a nice tool!
Nod, I've just finished reading this (something that I should have done long ago).
It is filled with lots of examples of this type of thing (and other bizarre parasitic cases) and talks a lot about the reasons for it.
In particular his idea of the 'Extended phenotype' where the influence of a gene is on the whole of the environment not just the 'vehicle' that carries and reproduces the gene.
Of course Gentoos version will be a kit car; it will give you 3 options for the level you want to start with:
* Preassembled body parts (doors, engine etc) - for the wimps.
* Precut, cast metal ready to assemble.
* Metal ore for the real hard cases.
Many of the online systems promise many things about encryption; I guess they all promise stuff is encrypted over the wire, and I guess most also state that stuff is encrypted on their storage servers.
But with what keys - and where are those stored?
I'm aware of at least one (very large!) online storage company who has a small note in their docs saying that the keys are stored 'in escrow' with them - i.e. everything is nice and safely encrypted but they have the keys to decrypt them!
They're docs also say how that key can get revealed to lawyers in some cases, and I think to end users who forget their keys.
What is needed here (but would of course be difficult to do - both politically and technically) is to make laws at the EU or US level that ban their companies from participating in censorship - probably impossible to get through though
Yep - exactly the same thing; Dell with pair of maxtors, one fell out of the RAID mirror and while rebuilding the other one went.
Another Dell server with maxtor drives lost its drive after 2 months.
One odd thing; in the first one SMART showed the drive was fine - passed every test, had no remapped sectors - but still had a log entry of uncorrectable error (seen by both the OS and in the SMART logs). WTF!
You know, the LSI SCSI cards are rather nice, they work with Linux; I don't know what their deal is with docs, but they seem to have contributed code.
(OK, so not directly related to Adaptec - but it seems to be a reasonable place to give their competitor a pat on the back!).
Oh - when I was talking about dodgy I didn't mean swearing (I don't care about those); I meant things about for example:
1) Other employees
2) Your boss
3) Your customers
I've seen some classic example of these.
So the really important thing is to really look through your code first - you need to:
1) Check it is all really your code - you didn't buy any in 5 years ago? If you have a source code control system then actually being able to trace your code is great.
2) Read the comments - ok, so lots of closed source contains rather dodgy comments that you might not want to be public.
3) Check that releasing it wouldn't be revealing any information you got under NDA from any of your suppliers/partners.
The related problems were already covered a few months ago on Slashdot:
l ?t id=137
http://it.slashdot.org/it/04/07/02/2348245.shtm
We caught a xerox network laser printer trying to send mail, by itself back to xerox; it tried three different outgoing smtp servers that fortunately our gateway blocked.
I don't know what was in those mails - but a google search revealed an article about a large data mining system based on Oracle; I think the main intent was to detect reasons for early failure - but who knows what happened to the data.