The NeXT boot sequence was quite pretty, graphical, and told you what was happening with minimal detail.
However sometimes you needed the real info, in which case there was an alternative boot time switch that let you do just that (I can't remember the exact process, but it would be equiv to adding a parameter to a lilo command line).
This has been talked of for quite a time, and is hardly radical. Whats more it is not an alternative to journal based filesystems, but logically its an adjunct to them.
First you have your filesystem that buffers transactions in a journal that is streamed to disk. Then, for performance, by avoiding all those extra seeks, you put the filesystem journal on another device - say a small fast dedicated disk. Then you make that device a NVRAM device rather than something based on spinning rust.
Whats more, if you are interested in something like mail systems, where you get a lot of transactions that *must* committed to stable storage (although a lot of MTAs don't do that in spite of the wording of RFC821), and you use a fileystem like ext3 with a data journalling mode, then putting the journal onto NVRAM makes a huge difference - by the time it comes to the point where data would be committed to the disk from the journal, most of the data (ie e-mail messages) is now unwanted (since the messages have been delivered to final local destination or for onward transmission) and so you don't even need to do the disk ops...
All of this is pretty much available now in ext3 other than the tools to get the journal onto a NVRAM disk - and thats just detail.
So, nice idea, needs more flesh, a little more infrastructure needed round it.
[Those who came to the London UKUUG Linux Conference might well have heard these discussions before going on in various corridors:-) ]
Visitors to Glasgow Central Station yesterday were surprised to
be confronted by a Ford Transit van with a small radar and rusty Sky
satellite dish mounted on top. What was this apparition? Why, the
BSA's latest weapon in the war against software-stealing
scum.
A wise reader asked one of the "consultants" what exactly the
dishes were able to do and was informed they could detect PCs running
illegal software. When pushed a little further, she admitted the van
was "just a dummy" but the BSA still had a fleet of the real things
rushing around Scotland detecting and nabbing unsuspecting
criminals.
This effectively only applies to intangible goods
on
EU Web Tax Proposed
·
· Score: 3
EU consumers already pay VAT and/or import duties on incoming goods from outside the EU (often along with a charge for collecting the taxes which seems particularly nasty.
This stuff is changing *where* the tax is paid - so on tangibles would have the advantage for EU people that they wouldn't be additionally hit for for the tax collecting charge. However it would mean that software delivered over the internet (look, no customs), would also be taxed.
As well as the Expo, Suse were also running a conference in the Olympia conference centre on the first day. This was a poorly advertised and poorly focused event - there were no titles given for the talks beforehand, and no real indication as to whether this was meant to be an introduction to Linux for those new to the phenomenum, or whether it was a development conference. In the end it was closer to the former, but with a good number of hardedned linuxers and even developers there....
Where this becomes relevant to the subject line (wow - relevant - thats an oddity), is the Maddog gave the closing talk - his chosen subject (chosen in the previous 24 hours) was "Why under 21s should not be excluded from these events".
Maddog spoke well, eloquently and amusingly on why he thought that the expo organisers were cutting themselves off from their own future by excluding people who may well already be making a significant contribution to linux development. Much of the background he gave is actually covered in the article in June 2000 Linux Journal.
As a postscript I would strongly advise people politely taking this issue up with IT Events and other conference organisers - it worked when we took up the issue of Debian and other non-profits attending the show.
Just for once, why not hold off on announcements until the sodding mirrors have updated. Then *more* people can get at the stuff quicker rather than the core site and the mirrors that are attempting to update being pounded into oblivion.
# exim filter # ----------- # Put this in your system filter - say #/etc/exim/system_file.exim # if $h_subject begins "ILOVEYOU" and not error_message then fail text "you appear to have a virus on your PC (see http://www.fsecure.com/v-descs/love.htm).\n Check your system, or rephrase the subject" endif
You need to call this filter from your config file, so add
message_filter =/etc/exim/system_filter.exim
to the main section - remember to HUP or restart exim after this.
The list archives have some ongoing discussion on this - including some more devious filters for VBS scripts.
USB only unless you pay much much more, manufacturer of the modems won't talk to anyone else, so a linux port will be hard.
BT only support windows (currently - might do Mac), and use proprietary authentication schemes - so its not just the modem you must drive but the other end too
Its a 50:1 contention ratio
Its firewalled and NATed to the point of uselessness - you ain't going to be able to connect back into a box on this service no nohow
BT OpenWorld are just a renamed BT Internet. BT Internet are clueless... so clueless they had to rename them, need I say more
All the other ADSL services within the next year are just going to be this resold - BT still own the local loop and are doing everything they can to keep it that way as long as they can
Basically we are stuck with this crap setup until BT are stripped of local loop monopoly
All MTAs that are halfway reliable are disk bound (*not* network bound) - I believe that Wietse has some information on this in the postfix data. This is because each message is fully commited to disk as it comes in (for exim this means opening (creating) writing, closing and flushing 2 files, other MTAs differ slightly), and then a reliable local delivery costs about the same.
Hence what you need to optomise is the latency of synchronous operations. So I would strongly recommend some form of RAID with NVRAM cache which means the commit time is memory speed rather than disk seek related.
Currently it looks to me as though there are 2 classes of users in this system - patients and doctors - although they appear to be basically be treated the same.
Although the numbers of doctors is relatively limited, the number of patients is presumably huge and relatively uncontrolled. In this case a 2 factor or token based authentication for the patients would appear infeasible - you are talking thousands of tokens here at a cost of 10's of dollars each. Additionally the patients are less of a compromise risk in that if you crack a patients account you only see the patients personal data. However the lesser number of doctors see personal data from lots of patients.
That makes me think that the patient end should be basically password driven (with a few wrinkles maybe, but not requiring additional hardware per patient). However the doctors end should have 2 factor authentication - and from my own experience of programming with SecurID I can't see why that would add more than a few days to the software design time.
A bigger issue is probably forcing logouts of users - an open window from a previous session is probably the biggest risk...
We all know that Hotmail runs on a *BSD/apache platform.
However people have said that it was the passport side that was broken, and this is a newer feature, which is used across several services. This raises questions (to me at least):-
Did this crack open up just Hotmail or all the passport services?
Was it a problem with the implementation of these systems or a fundemental design problem with the platforms?
If its an OS issue, what OS was affected - ie what is passport running on?
How is the system being made more inherently secure - rather than just patching cracks as they appear?
So many questions, so little chance of answers:-(
Was anything about the technique posted by the crackers?
RPM has been the format used by RH since RH 2.0. When 2.0 came out Caldera wasn't even (effectively) a Red Hat reseller - they appeared rather later on the scene.
RPM (the program) started as a perl program, and migrated into C (I think at the time of the RH 3.03 release). It has been significantly upgraded since then. I was involved a little for much of that time and remember the development being driven by Erik Troan with some input from Donnie Barnes and nothing signicant that I remember from any Caldera person that hit the mailing list.
There seems to be some revision of history going on right now. Red Hat are toungue-tied by the IPO and Caldera are getting talked up a lot suddenly while half truths about Red Hat get put into the mix. I have this feeling that there is a very very nasty smell coming from somewhere and it seems to be from Caldera's direction.
[For fans of legalities, I am not associated with RH in any way other than being yet another coder who has bounced code off them. My only involvement with Caldera is that they kindly sent me a copy of OpenLinux since I had my name in the kernel]
If Red Hat switched their distribution (or one incarnation of it) so that all the final integration and packaging was done in Europe, added in some non-US derived crypto packages - ie ssh, gpg & mod_ssl, and were obviously careful about where orders were being fufilled from, they could produce a distro with decent crypto [at least until the EU finally rolls over and does everything the US asks].
RedHat 6.0 includes rdist 6.1.5 which is under the Magnicorp license.
The answer is to fork from the last free rdist version and then merge in any relevant bug fixes (you probably need to clean room this so that you aren't accused of just hijacking the Magnicorp version). Could this code fork be transfered to GPL?
BTW RedHat used to use a different rdist. The Michael Cooper version is much superior and we want to stay with that if at all possible. People do need an rdist version - rsync can't do somethings at present (ie script triggers on updates) although modifying rsync in that way is another option.
Basically internet provision does cost more in the UK than in the US - mostly because 90% of access involves going off to the US (directly or indirectly). UK internet companies pay for all these expensive transatlantic links to the US (US providers need far less international transit, and anyhow they can normally freeload on their peers). So there is a higher cost involved with UK connectivity which can only be resolved by having very cheap transatlantic or not needing transatlantic (one requires reducating the transatlantic carriers, the other means that all the required content has to be locally available).
As UK connectivity costs more, and specifically has close to a per-byte aspect to it due to the non-UK traffic, the charging has to be different. Currently there are 3 ways of getting people to pay for internet:- 1. Monthly fees 2. Per second phone charges (the ISP gets a cut) 3. Sell advertising
Most ISPs use a combination with varying degrees of each. If you go to unmetered local calls then all this has to be paid for somewhere, so it will either be larger monthly fees (probably with usage limits) or enforced advertising - which often means that linux is not just unsupported but strongly discriminated against (because you clever linux users work round the advertising presentation).
The UK is not the same as the US, so don't just assume US solutions will work there, and don't just think that someone else will pay for it - you need a fair and consistant charging model. I'm not saying the current one is that, but to succeed a replacement must both be reasonable for users and allow the ISPs to stay in business.
Around the end of Q1/99, the ISP league table was:-
1. Freeserve (Planet Online/Energis)
2. AOL
3. Compuserve
4. Demon
Even if you don't include AOL/Compuserve as ISPs, then Demon are still less than 25% of the size of Freeserve.
I'm not in the ISP market now so haven't followed this further, but my gut feeling says that FS is bigger, AOL/Compuserve have shrunk a little, Demon will have lost customers but they take forever to kill old accounts so will still count them. One of the other freebies may have over taken possibly getting as high as #2, but FS will still be on top for now.
isn't this just showing at least one of the ways that the free software community works - no one owns it so there tends not to be centralisation of control or even resources. Instead we get a flush of people doing similar things and the best of them survive. Often several reasonable projects fold together to make a really good one. Don't knock it - it works, even if in someways its about as efficient as plain standard evolution it has the same result in that the best adapted survive.
I think that all of these efforts should probably have a comments button for each page so that each vistor can add to the knowlege base - only solution would be to have a faq-o-matic style site which just grows and self edits by rating peoples comments - in fact/. could be that site!
2.0 Linux had a reasonable, but not brilliant client - certainly slower than the better commercial unices. It didn't do locking (at all), but was pretty stable (we had some occaisional problems on SPARC, but none on intel). If you didn't need locking then it worked fine (the other performance benefits of Linux outweighed the NFS degredation).
2.2 Linux is meant to be much better performance and locking is getting there... but its currently flakey. However I haven't used it seriously yet so ignore me on post 2.0 NFS:-)
I don't understand the number of criticisms I've seen over the past few months saying that Linux doesn't support multiple processors.
The only thing I can think of is that distributions generally do not install an SMP kernel by default, but make it an additional option. Is the person who researched these reports capable of changing a base installed config.
Bills in town to talk up his book (at better than $1.50 list per page it needs a lot of talking up especially given reviews like the ones he's got). Bill therefore wants publicity. Linux is media friendly currently. Hence mention Linux just to get yourself more publicity.
[Relating to the embedded article on open source security]
Open source gives you the ability to improve security by inspecting the code. It does not make anything inherently more secure, other than people tend to find things in source which would only be discovered by black box testing without source, and with many eyes all bugs are shallow.
If someone modifies your kernel source, and you use that source without detecting this then you have no better security than a closed system bought with your eyes shut.
Long ago there was a theoretical example of a "virus" (for want of a better term) which inhabited a C compiler, and hooked its code into any new builds of the C compiler, and was effectively invisible (the virus source was basically pasted into the files during the compile process). [I would love it if someone could give me the ref to this - I heard about it in my University course back in 84)]
Similarly a hacked kernel could probably have hooks in it to infect future kernel builds. Open source or not this is close to undetectable....
So basically although open source makes things more open, your security still depends on trusting (or verifying) the source (code or originator) of all your system components - other than standard practices for operating in a reasonably hostile environment.
Slashdot Mirror
The NeXT boot sequence was quite pretty, graphical, and told you what was happening with minimal detail.
However sometimes you needed the real info, in which case there was an alternative boot time switch that let you do just that (I can't remember the exact process, but it would be equiv to adding a parameter to a lilo command line).
This has been talked of for quite a time, and is hardly radical. Whats more it is not an alternative to journal based filesystems, but logically its an adjunct to them.
:-) ]
First you have your filesystem that buffers transactions in a journal that is streamed to disk. Then, for performance, by avoiding all those extra seeks, you put the filesystem journal on another device - say a small fast dedicated disk. Then you make that device a NVRAM device rather than something based on spinning rust.
Whats more, if you are interested in something like mail systems, where you get a lot of transactions that *must* committed to stable storage (although a lot of MTAs don't do that in spite of the wording of RFC821), and you use a fileystem like ext3 with a data journalling mode, then putting the journal onto NVRAM makes a huge difference - by the time it comes to the point where data would be committed to the disk from the journal, most of the data (ie e-mail messages) is now unwanted (since the messages have been delivered to final local destination or for onward transmission) and so you don't even need to do the disk ops...
All of this is pretty much available now in ext3 other than the tools to get the journal onto a NVRAM disk - and thats just detail.
So, nice idea, needs more flesh, a little more infrastructure needed round it.
[Those who came to the London UKUUG Linux Conference might well have heard these discussions before going on in various corridors
This can be found at The Register in this story
A partial quote
Visitors to Glasgow Central Station yesterday were surprised to be confronted by a Ford Transit van with a small radar and rusty Sky satellite dish mounted on top. What was this apparition? Why, the BSA's latest weapon in the war against software-stealing scum.
A wise reader asked one of the "consultants" what exactly the dishes were able to do and was informed they could detect PCs running illegal software. When pushed a little further, she admitted the van was "just a dummy" but the BSA still had a fleet of the real things rushing around Scotland detecting and nabbing unsuspecting criminals.
EU consumers already pay VAT and/or import duties on incoming goods from outside the EU (often along with a charge for collecting the taxes which seems particularly nasty.
This stuff is changing *where* the tax is paid - so on tangibles would have the advantage for EU people that they wouldn't be additionally hit for for the tax collecting charge. However it would mean that software delivered over the internet (look, no customs), would also be taxed.
Can it be implemented, can it hell.
As well as the Expo, Suse were also running a conference in the Olympia conference centre on the first day. This was a poorly advertised and poorly focused event - there were no titles given for the talks beforehand, and no real indication as to whether this was meant to be an introduction to Linux for those new to the phenomenum, or whether it was a development conference. In the end it was closer to the former, but with a good number of hardedned linuxers and even developers there....
Where this becomes relevant to the subject line (wow - relevant - thats an oddity), is the Maddog gave the closing talk - his chosen subject (chosen in the previous 24 hours) was "Why under 21s should not be excluded from these events".
Maddog spoke well, eloquently and amusingly on why he thought that the expo organisers were cutting themselves off from their own future by excluding people who may well already be making a significant contribution to linux development. Much of the background he gave is actually covered in the article in June 2000 Linux Journal.
As a postscript I would strongly advise people politely taking this issue up with IT Events and other conference organisers - it worked when we took up the issue of Debian and other non-profits attending the show.
Just for once, why not hold off on announcements until the sodding mirrors have updated. Then *more* people can get at the stuff quicker rather than the core site and the mirrors that are attempting to update being pounded into oblivion.
Responsible reporting doesn't mean first post.
Someone has posted a recipe for postfix here
I'm told you can just adapt the Melissa one for sendmail
Here is the recipe for exim
You need to call this filter from your config file, so add
to the main section - remember to HUP or restart exim after this.
The list archives have some ongoing discussion on this - including some more devious filters for VBS scripts.
Basically we are stuck with this crap setup until BT are stripped of local loop monopoly
Surely an example of good ethics is doing your own homework assignments rather than just posting the questions to "Ask Slashdot"?
[with thanks to hobbit]
All MTAs that are halfway reliable are disk bound (*not* network bound) - I believe that Wietse has some information on this in the postfix data.
This is because each message is fully commited to disk as it comes in (for exim this means opening (creating) writing, closing and flushing 2 files, other MTAs differ slightly), and then a reliable local delivery costs about the same.
Hence what you need to optomise is the latency of synchronous operations. So I would strongly recommend some form of RAID with NVRAM cache which means the commit time is memory speed rather than disk seek related.
Currently it looks to me as though there are 2 classes of users in this system - patients and doctors - although they appear to be basically be treated the same.
Although the numbers of doctors is relatively limited, the number of patients is presumably huge and relatively uncontrolled. In this case a 2 factor or token based authentication for the patients would appear infeasible - you are talking thousands of tokens here at a cost of 10's of dollars each. Additionally the patients are less of a compromise risk in that if you crack a patients account you only see the patients personal data. However the lesser number of doctors see personal data from lots of patients.
That makes me think that the patient end should be basically password driven (with a few wrinkles maybe, but not requiring additional hardware per patient). However the doctors end should have 2 factor authentication - and from my own experience of programming with SecurID I can't see why that would add more than a few days to the software design time.
A bigger issue is probably forcing logouts of users - an open window from a previous session is probably the biggest risk...
We all know that Hotmail runs on a *BSD/apache platform.
However people have said that it was the passport side that was broken, and this is a newer feature, which is used across several services. This raises questions (to me at least):-
So many questions, so little chance of answers :-(
Was anything about the technique posted by the crackers?
RPM has been the format used by RH since RH 2.0. When 2.0 came out Caldera wasn't even (effectively) a Red Hat reseller - they appeared rather later on the scene.
RPM (the program) started as a perl program, and migrated into C (I think at the time of the RH 3.03 release). It has been significantly upgraded since then. I was involved a little for much of that time and remember the development being driven by Erik Troan with some input from Donnie Barnes and nothing signicant that I remember from any Caldera person that hit the mailing list.
There seems to be some revision of history going on right now. Red Hat are toungue-tied by the IPO and Caldera are getting talked up a lot suddenly while half truths about Red Hat get put into the mix. I have this feeling that there is a very very nasty smell coming from somewhere and it seems to be from Caldera's direction.
[For fans of legalities, I am not associated with RH in any way other than being yet another coder who has bounced code off them. My only involvement with Caldera is that they kindly sent me a copy of OpenLinux since I had my name in the kernel]
If Red Hat switched their distribution (or one incarnation of it) so that all the final integration and packaging was done in Europe, added in some non-US derived crypto packages - ie ssh, gpg & mod_ssl, and were obviously careful about where orders were being fufilled from, they could produce a distro with decent crypto [at least until the EU finally rolls over and does everything the US asks].
This would definitely be a good thing.
RedHat 6.0 includes rdist 6.1.5 which is under the Magnicorp license.
The answer is to fork from the last free rdist version and then merge in any relevant bug fixes (you probably need to clean room this so that you aren't accused of just hijacking the Magnicorp version). Could this code fork be transfered to GPL?
BTW RedHat used to use a different rdist. The Michael Cooper version is much superior and we want to stay with that if at all possible. People do need an rdist version - rsync can't do somethings at present (ie script triggers on updates) although modifying rsync in that way is another option.
Basically internet provision does cost more in the UK than in the US - mostly because 90% of access involves going off to the US (directly or indirectly). UK internet companies pay for all these expensive transatlantic links to the US (US providers need far less international transit, and anyhow they can normally freeload on their peers). So there is a higher cost involved with UK connectivity which can only be resolved by having very cheap transatlantic or not needing transatlantic (one requires reducating the transatlantic carriers, the other means that all the required content has to be locally available).
As UK connectivity costs more, and specifically has close to a per-byte aspect to it due to the non-UK traffic, the charging has to be different. Currently there are 3 ways of getting people to pay for internet:-
1. Monthly fees
2. Per second phone charges (the ISP gets a cut)
3. Sell advertising
Most ISPs use a combination with varying degrees of each. If you go to unmetered local calls then all this has to be paid for somewhere, so it will either be larger monthly fees (probably with usage limits) or enforced advertising - which often means that linux is not just unsupported but strongly discriminated against (because you clever linux users work round the advertising presentation).
The UK is not the same as the US, so don't just assume US solutions will work there, and don't just think that someone else will pay for it - you need a fair and consistant charging model. I'm not saying the current one is that, but to succeed a replacement must both be reasonable for users and allow the ISPs to stay in business.
Around the end of Q1/99, the ISP league table was:-
1. Freeserve (Planet Online/Energis)
2. AOL
3. Compuserve
4. Demon
Even if you don't include AOL/Compuserve as ISPs, then Demon are still less than 25% of the size of Freeserve.
I'm not in the ISP market now so haven't followed this further, but my gut feeling says that FS is bigger, AOL/Compuserve have shrunk a little, Demon will have lost customers but they take forever to kill old accounts so will still count them. One of the other freebies may have over taken possibly getting as high as #2, but FS will still be on top for now.
As for ownership:-
Freeserve - Planet - owned by Energis (telco)
Demon - owned by Scottish power/telecom
Tesco - effectively owned by BT
[various others] - effectively BT clickfree
isn't this just showing at least one of the ways that the free software community works - no one owns it so there tends not to be centralisation
/. could be that site!
of control or even resources. Instead we get a flush of people doing similar things and the best of them survive. Often several reasonable projects fold together to make a really good one. Don't knock it - it works, even if in someways its about as efficient as plain standard evolution it has the same result in that the best adapted survive.
I think that all of these efforts should probably have a comments button for each page so that each vistor can add to the knowlege base - only solution would be to have a faq-o-matic style site which just grows and self edits by rating peoples comments - in fact
Linux of 1.2 and prior era had lousy NFS.
:-)
2.0 Linux had a reasonable, but not brilliant client - certainly slower than the better commercial unices. It didn't do locking (at all), but was pretty stable (we had some occaisional problems on SPARC, but none on intel). If you didn't need locking then it worked fine (the other performance benefits of Linux outweighed the NFS degredation).
2.2 Linux is meant to be much better performance and locking is getting there... but its currently flakey. However I haven't used it seriously yet so ignore me on post 2.0 NFS
I don't understand the number of criticisms I've seen over the past few months saying that Linux doesn't support multiple processors.
The only thing I can think of is that distributions generally do not install an SMP kernel by default, but make it an additional option. Is the person who researched these reports capable of changing a base installed config.
Bills in town to talk up his book (at better than $1.50 list per page it needs a lot of talking up especially given reviews like the ones he's got). Bill therefore wants publicity. Linux is media friendly currently. Hence mention Linux just to get yourself more publicity.
:-)
Am I cynical....
[Relating to the embedded article on open source security]
Open source gives you the ability to improve security by inspecting the code. It does not make anything inherently more secure, other than people tend to find things in source which would only be discovered by black box testing without source, and with many eyes all bugs are shallow.
If someone modifies your kernel source, and you use that source without detecting this then you have no better security than a closed system bought with your eyes shut.
Long ago there was a theoretical example of a "virus" (for want of a better term) which inhabited a C compiler, and hooked its code into any new builds of the C compiler, and was effectively invisible (the virus source was basically pasted into the files during the compile process). [I would love it if someone could give me the ref to this - I heard about it in my University course back in 84)]
Similarly a hacked kernel could probably have hooks in it to infect future kernel builds. Open source or not this is close to undetectable....
So basically although open source makes things more open, your security still depends on trusting (or verifying) the source (code or originator) of all your system components - other than standard practices for operating in a reasonably hostile environment.