> My sense is the latter requires more technical skill "in house",
Munich has spent a considerable amount of time to develop these skills in the last years. Also, employee turnover in this sector is very low. So once somebody works there, he seldomly leaves (and takes knowledge with him).
> frankly am skeptical that it makes sense to keep your own source tree
This has to be seen. Munich probably hopes that most of the changes go back into the upstream channel. I also don't know how large the diffs are. May be big, may be trivial. May also be just an add-on package that can be easily ported to newer releases of the upstream source.
> and "hire a guy to fix a nasty bug" as the grandparent suggested, > but I have minimal understanding of the OSS model so I can't really say for sure.
Most of this is still to be seen. But as others have pointed out: the move was also needed to get legacy apps EOLed, move everything to webservices and generally clean-up the IT-strategy.
> Is part of the project to replicate Microsoft's update mechanism?
Yes.
> Are they planning on maintaining their own source tree > for all applications and the OS?
IIRC, sort-of yes. They developed their own Debian based "distribution".
On a 14k clients-scale, there are no out-of-the-box solutions anyway. Not in MSFT-land, not in Novell-land and certainly not in LNX-land. So, you've got to do your own calculations to see what makes sense for you. Munich made theirs, you'd make yours. Big deal. A complete NT4->W2K3 replacement would not have been much easier, either - and XP is now little more than a legacy OS - they'd have to start rolling out Vista soon anyway.
The problem was that after these visits, people in the council suddenly realized just how much they had overpayed all the years. You, me and the rest of slashdot knew this for long - but at that moment, even the non-IT city-council members must have had one of these "WTF?"-moments. MSFT had fobbed them off with tiny rebates over the years and now they looked like idiots. Like those first-year purchasing agents that are so proud of getting double-digit rebates on "list-prices", only to realize afterwards that the list-prices had been inflated 20% just for them. And when politicians are made look like idiots, they sometimes do just the opposite of what is proposed to them.
I assume the local MSFT-branch (located a little outside of Munich) knew this, to a certain extent - but was pressed into a "hard-selling" tactic by Redmond. It's probably not a good time to start an argument when Steve Ballmer is breathing down your neck...
It should be noted that Mayor Christian Ude's PC is slated to be among the first batch of systems to run the Debian-based Linux-desktop Munich will be using.
Instead of fixing the real problem, they create another code-layer ontop. Reminds me of those comedy-scenes, where people try to set a shaky table straight by shortening one leg - and then shortening it to much, resulting in three legs that are too long, then cutting these...until all the legs are cut to zero. No wonder so little of MS-Research ends-up in products - but in this light, it might not be bad after all.
[root@lin-01 ~]# sg_scan -bash: sg_scan: command not found [root@lin-01 ~]# cat/etc/redhat-release Red Hat Enterprise Linux ES release 4 (Nahant Update 3)
Come back when the kernel offers an API for that, and a utility to use it. You'd be pissed, too, if ifconfig(8) didn't exist and you'd have to peek and poke at procfs to get networking running.
> Unplug the drives, and the Linux/dev files go away. (udevd deletes them) > Plug them in again in different locations, and watch the/dev files come back: > same name, same permissions, even if the device numbers change
Even if I plug in a different burner?
>On FreeBSD you can do the -scanbus thing, unplug and replug the burners, > then burn the wrong CD because the ID numbers changed.
You have to rescan the bus again, of course;-) And use the output in cdrecord.
> It's been a damn long time since I've needed to rescan a SCSI bus.
Not for me.
Even in Linux-kernel 2.6 land. Or even more so.
Hint: I have to work with FC.
> When I plug in a device, the/dev files appear automatically.
Not here, on my servers attached to the Fibre-Channel Switch. The missing camcontrol(8) devlist makes this especially painfull.
But: the "name-thing" is nice - until you realize that two different USB-sticks mount at different places and you have to guess which/media subdirectory it actually is (with SuSE, I don't know about others), because it doesn't seem to delete the old ones...
> What if some cd-burner comes along and isn't even remotely scsi-based
Because SCSI is portable. Also, SCSI isn't dead. To the contrary. For the above reason, more and more SATA-controllers begin to look to the OS as SCSI-controllers. SCSI as a bus (with the 8/16 bit ultra-bla-lvd-terminator-cabling-mess) may be dead - but the command-language will live for a long time.
> He has the gall to claim that users actually like to specify all burners by a 1980s-style set of three numbers,
Hey - I actually thought it to be normal. Because, in FreeBSD-land, there's camcontrol(8) devlist, which gives you exactly these numbers. Also, some people may have more than one burner. The above makes it very obvious, which one is the right one.
> and that users actually like running the -scanbus option instead of just using/dev/burner
It's a legacy, maybe - but just try to find a command in Linux to rescan your SCSI-bus. Well, there isn't. Instead, you are supposed to echo some values into certain parts of the procfs, or run some vendor-specific script. Wow, l33t. Impressive. *That's* what I call a hack.
Yes, cdrecord is still living in SCSI-land - but this is the only cross-platform (API-) stable peripheral interface that works on almost any unix-platform. Nowadays, too much open-source software is full of code that assume that everybody=linux - or those stupid install-scripts that assume sh=bash. I *loathe* them.
And, as someone else pointed out: if it would be so easy-peasy to code a cdrecord replacement, somebody would have done it already. But apparently, some people prefer to fight over licences, rather than actually produce code... (This is not to put down the OpenBSD-project, who also fight for free-ness of code - but they actually go the extra-mile and have the guts to start from scratch, if it is necessary. In Linux-land, forking a GPLed older version seems to be de-rigeur - any counter-examples?)
In FreeBSD-land, they knew this 10 years ago already. We can be glad that at least the kernel is developed in a sensible way (with lots of room for improvement, nevertheless)
> Are you sure they have multiple (more than two) ethernet interfaces and not just two with multiple ports on the internal interface?
Well, they are independant interfaces - but due to architecture limitations, the total interface-to-interface filter-performance is limited. IIRC, the WRAP maxes out at around 30 MBit/s. I'm not sure about the Soekris, but it may go a bit higher. These are really embedded platforms with focus on space- and power-consumption limitation. They can provide a very powerful solution to home and SOHO users (see www.pfsense.org for a Firewall-One killer). But their throughput is limited. For anything that has to be able to cope with multiple saturated FE-interfaces, PCI-X or PCIe is recommeded.
That was almost 12 years ago. Wow. Does this have any relevance to today's aviation? Because two weeks ago nobody cared about the contents of your wash-bag. I don't believe people have not been running risk-assessments between 2001 and now. If they had seen a chance that somebody could successfully bring a bomb on board, why on earth did they not outlaw liquids 10 years ago? Or 4 years ago? Nitroglycerin should now be easily detected anyway (and it's so unstable that I wonder how he brought it on board "safe" at all). TFA was talking about all the smoke the authorities have been putting up without presenting anything _substancial_ other than a confession most probably made under torture (the authorities more or less openly coquetting with this fact).
'nuff said. Or are the findings "secret" and "not for public viewing"? With all the media-buzz about these "bombings", I find it silly that people (and journalists first of all) fail to ask the single most important question: "Where's the evidence?" If one wants to believe the official press-communication, the "terrorists" were "very close" to actually boarding their planes and let the fireworks begin - yet not a single of those "liquid bombs" has been shown to the public. Meanwhile, security-personel is making women drink baby-milk... The article sums this all up very nicely. If you haven't read it, go and RTFA.
Let's hope the Telco's equipment also works underwater - or is at least water-proof. Because one thing is sure: New Orleans is going so sink into the ocean rather sooner than later. Just the people (left) living there haven't caught up to the reality, it seems. But the term "sinking billions in infrastructure" suddenly makes more sense, right?
> Those really big boats rely on the same class of diminishing and climate-affecting fuels, [snip]
Not completely true. We will see the return of the sail-fraighter soon. Very soon. Unfortunately, the high cost of fuel will lead to skyrocketing prices for things like fresh bananas, pineapples etc.
I will really miss them.
I don't think it's too bad - it's the publicity
on
Apple's Growing Pains
·
· Score: 1
From the comments of other, long-time Mac-users, I'd conclude that the current generation of products is not too bad, especially not for "Gen. 1" products. Talk to long-time Mac-Addicts and they will relay horror-stories about virtually any Apple-product in the last years. But who cared about Apple notebooks 3-5 years ago? It's only recently that they moved themselves into the limelight. One reason why they moved so slow on all the Macbook-motherboard-issues may be that they first wanted to do a complete assessment of the problem, rather than do a messy "trial and error" exchange, like so many vendors do where you get the notebook "repaired" with the original problem still persisting and new errors added... (could probably get an Apple-Repair-horror-story about that, too...).
Slashdot Mirror
> My sense is the latter requires more technical skill "in house",
Munich has spent a considerable amount of time to develop these skills in the last years.
Also, employee turnover in this sector is very low. So once somebody works there, he seldomly leaves (and takes knowledge with him).
> frankly am skeptical that it makes sense to keep your own source tree
This has to be seen. Munich probably hopes that most of the changes go back into the upstream channel.
I also don't know how large the diffs are. May be big, may be trivial. May also be just an add-on package that can be easily ported to newer releases of the upstream source.
> and "hire a guy to fix a nasty bug" as the grandparent suggested,
> but I have minimal understanding of the OSS model so I can't really say for sure.
Most of this is still to be seen.
But as others have pointed out: the move was also needed to get legacy apps EOLed, move everything to webservices and generally clean-up the IT-strategy.
> Is part of the project to replicate Microsoft's update mechanism?
Yes.
> Are they planning on maintaining their own source tree
> for all applications and the OS?
IIRC, sort-of yes.
They developed their own Debian based "distribution".
On a 14k clients-scale, there are no out-of-the-box solutions anyway. Not in MSFT-land, not in Novell-land and certainly not in LNX-land.
So, you've got to do your own calculations to see what makes sense for you.
Munich made theirs, you'd make yours. Big deal.
A complete NT4->W2K3 replacement would not have been much easier, either - and XP is now little more than a legacy OS - they'd have to start rolling out Vista soon anyway.
The problem was that after these visits, people in the council suddenly realized just how much they had overpayed all the years.
You, me and the rest of slashdot knew this for long - but at that moment, even the non-IT city-council members must have had one of these "WTF?"-moments.
MSFT had fobbed them off with tiny rebates over the years and now they looked like idiots. Like those first-year purchasing agents that are so proud of getting double-digit rebates on "list-prices", only to realize afterwards that the list-prices had been inflated 20% just for them.
And when politicians are made look like idiots, they sometimes do just the opposite of what is proposed to them.
I assume the local MSFT-branch (located a little outside of Munich) knew this, to a certain extent - but was pressed into a "hard-selling" tactic by Redmond. It's probably not a good time to start an argument when Steve Ballmer is breathing down your neck...
AFAIK, they wanted to avoid swapping one vendor-lock with another.
At the time, there was no OpenSuSE like now.
cheers,
Rainer
sigh.
u x%E2%80%94Free_Software_for_Munich
that site has general information about the Linux-Project and a link to this site:
http://www.ssrc.org/wiki/POSA/index.php?title=LiM
> Why Debian?
1 47197/index.html
See here:
http://www.muenchen.de/Rathaus/dir/limux/english/
OK?
It should be noted that Mayor Christian Ude's PC is slated to be among the first batch of systems to run the Debian-based Linux-desktop Munich will be using.
> Melting of the North polar ice cap makes no difference to sea levels.
Indeed.
Unfortunately, Greenland's ice glaciers are also melting, the island is getting greener every year. *That* ice cap does matter.
> many of you would love that just to stick it to MS,
> but you'd be screwing over Zune's users in the process
Collateral damage.
Instead of fixing the real problem, they create another code-layer ontop.
Reminds me of those comedy-scenes, where people try to set a shaky table straight by shortening one leg - and then shortening it to much, resulting in three legs that are too long, then cutting these...until all the legs are cut to zero.
No wonder so little of MS-Research ends-up in products - but in this light, it might not be bad after all.
So funny.
/etc/redhat-release
> sg_scan
[root@lin-01 ~]# sg_scan
-bash: sg_scan: command not found
[root@lin-01 ~]# cat
Red Hat Enterprise Linux ES release 4 (Nahant Update 3)
Come back when the kernel offers an API for that, and a utility to use it.
You'd be pissed, too, if ifconfig(8) didn't exist and you'd have to peek and poke at procfs to get networking running.
Until then: back to the basement.
> Unplug the drives, and the Linux /dev files go away. (udevd deletes them) /dev files come back:
;-)
/dev files appear automatically.
/media subdirectory it actually is (with SuSE, I don't know about others), because it doesn't seem to delete the old ones...
> Plug them in again in different locations, and watch the
> same name, same permissions, even if the device numbers change
Even if I plug in a different burner?
>On FreeBSD you can do the -scanbus thing, unplug and replug the burners,
> then burn the wrong CD because the ID numbers changed.
You have to rescan the bus again, of course
And use the output in cdrecord.
> It's been a damn long time since I've needed to rescan a SCSI bus.
Not for me.
Even in Linux-kernel 2.6 land. Or even more so.
Hint: I have to work with FC.
> When I plug in a device, the
Not here, on my servers attached to the Fibre-Channel Switch.
The missing camcontrol(8) devlist makes this especially painfull.
But: the "name-thing" is nice - until you realize that two different USB-sticks mount at different places and you have to guess which
> What if some cd-burner comes along and isn't even remotely scsi-based
Because SCSI is portable.
Also, SCSI isn't dead. To the contrary. For the above reason, more and more SATA-controllers begin to look to the OS as SCSI-controllers.
SCSI as a bus (with the 8/16 bit ultra-bla-lvd-terminator-cabling-mess) may be dead - but the command-language will live for a long time.
> He has the gall to claim that users actually like to specify all burners by a 1980s-style set of three numbers,
/dev/burner
Hey - I actually thought it to be normal.
Because, in FreeBSD-land, there's camcontrol(8) devlist, which gives you exactly these numbers.
Also, some people may have more than one burner. The above makes it very obvious, which one is the right one.
> and that users actually like running the -scanbus option instead of just using
It's a legacy, maybe - but just try to find a command in Linux to rescan your SCSI-bus.
Well, there isn't. Instead, you are supposed to echo some values into certain parts of the procfs, or run some vendor-specific script.
Wow, l33t. Impressive. *That's* what I call a hack.
Yes, cdrecord is still living in SCSI-land - but this is the only cross-platform (API-) stable peripheral interface that works on almost any unix-platform.
Nowadays, too much open-source software is full of code that assume that everybody=linux - or those stupid install-scripts that assume sh=bash.
I *loathe* them.
And, as someone else pointed out: if it would be so easy-peasy to code a cdrecord replacement, somebody would have done it already.
But apparently, some people prefer to fight over licences, rather than actually produce code...
(This is not to put down the OpenBSD-project, who also fight for free-ness of code - but they actually go the extra-mile and have the guts to start from scratch, if it is necessary. In Linux-land, forking a GPLed older version seems to be de-rigeur - any counter-examples?)
In FreeBSD-land, they knew this 10 years ago already.
We can be glad that at least the kernel is developed in a sensible way (with lots of room for improvement, nevertheless)
> Are you sure they have multiple (more than two) ethernet interfaces and not just two with multiple ports on the internal interface?
Well, they are independant interfaces - but due to architecture limitations, the total interface-to-interface filter-performance is limited.
IIRC, the WRAP maxes out at around 30 MBit/s.
I'm not sure about the Soekris, but it may go a bit higher.
These are really embedded platforms with focus on space- and power-consumption limitation.
They can provide a very powerful solution to home and SOHO users (see www.pfsense.org for a Firewall-One killer).
But their throughput is limited.
For anything that has to be able to cope with multiple saturated FE-interfaces, PCI-X or PCIe is recommeded.
cheers,
Rainer
That was almost 12 years ago.
Wow.
Does this have any relevance to today's aviation? Because two weeks ago nobody cared about the contents of your wash-bag.
I don't believe people have not been running risk-assessments between 2001 and now. If they had seen a chance that somebody could successfully bring a bomb on board, why on earth did they not outlaw liquids 10 years ago? Or 4 years ago?
Nitroglycerin should now be easily detected anyway (and it's so unstable that I wonder how he brought it on board "safe" at all).
TFA was talking about all the smoke the authorities have been putting up without presenting anything _substancial_ other than a confession most probably made under torture (the authorities more or less openly coquetting with this fact).
> You probably already know this, but for the benefit of... ...snip....
All well, but at least in Unix-land, they did get vi(1) on board - which MSFT failed to do.
FreeBSD's single user mode still doesn't have vi(1) but ed(1), BTW - which I cannot use at all...
> so I'm sure the writers could have had him create an explosion out of contact-lense solution if they wanted.
Contact-lense solution is of course also no longer allowed on a plane.
Somebody has been watching MacGyver too much, methinks.
'nuff said.
Or are the findings "secret" and "not for public viewing"?
With all the media-buzz about these "bombings", I find it silly that people (and journalists first of all) fail to ask the single most important question:
"Where's the evidence?"
If one wants to believe the official press-communication, the "terrorists" were "very close" to actually boarding their planes and let the fireworks begin - yet not a single of those "liquid bombs" has been shown to the public.
Meanwhile, security-personel is making women drink baby-milk...
The article sums this all up very nicely. If you haven't read it, go and RTFA.
Let's hope the Telco's equipment also works underwater - or is at least water-proof.
Because one thing is sure: New Orleans is going so sink into the ocean rather sooner than later. Just the people (left) living there haven't caught up to the reality, it seems.
But the term "sinking billions in infrastructure" suddenly makes more sense, right?
In German, but you get the idea from the pictures:4 27494,00.html.
http://www.spiegel.de/wissenschaft/mensch/0,1518,
This site says the chance of getting hit by luggage theft is 2% on a round-trip.
The same site also advises you to
Oh-my...
> Those really big boats rely on the same class of diminishing and climate-affecting fuels,
[snip]
Not completely true.
We will see the return of the sail-fraighter soon. Very soon.
Unfortunately, the high cost of fuel will lead to skyrocketing prices for things like fresh bananas, pineapples etc.
I will really miss them.
From the comments of other, long-time Mac-users, I'd conclude that the current generation of products is not too bad, especially not for "Gen. 1" products.
Talk to long-time Mac-Addicts and they will relay horror-stories about virtually any Apple-product in the last years.
But who cared about Apple notebooks 3-5 years ago?
It's only recently that they moved themselves into the limelight.
One reason why they moved so slow on all the Macbook-motherboard-issues may be that they first wanted to do a complete assessment of the problem, rather than do a messy "trial and error" exchange, like so many vendors do where you get the notebook "repaired" with the original problem still persisting and new errors added... (could probably get an Apple-Repair-horror-story about that, too...).