The problem with advertising based revenue, or 'subscriber-choice' based revenue is simple.. everything revolves around the numbers. The 'experts' can happily say that show a will attract x million viewers because it fits into the same mould as another show that got a similar number of viewers, whereas with show b - which is a completely original affair, or a departure from the current norm - they have no idea, no frame of reference to say that it is going to make so many millions in revenue. Most companies will therefore stick with the same-old same-old tried and tested variants of Big Brother. Organisations like the BBC have extra freedom to experiment somewhat, and therefore do a lot of quality non-mainstream programmes (I presume that many of the ones I don't like have a quality an purity of their own) including a hell of a lot of excellent stuff that would very rarely even be attempted elsewhere - things like Monty Python, Dr. Who, Neverwhere, HHGTTG, Hustle, Red Dwarf, Blackadder, Little Britain to name but a few. They are encouraged to 'push the envelope' rather than chase ratings. Sure, there are some notable experiments in the ratings sector (Ultraviolet, 24 and BSG spring to mind), but these are relatively few and far between in comparison to the BBC's gems.
I'm happy to shell out my hard-earned for a situation that engenders creative programming.
especially when the gift was costing you around $500,000/year.
How was it costing them that much?
Such figures are just like the IRAA's 'cost of piracy' figures - pure Bull.
Look at the 'cost'..
is it costing BK the value of the licenses?.. No. That's revenue that they could have gained if the kernel developers chose to buy it independantly
is it the cost of developing bug-fixes?.. don't make me laugh - they have to do that anyways.
Is is the cost of implementing features necessary for a huge distributed development team?.. considering that this is precisely what BK was designed for, a large amount of such improvements would be required or requested by their paying customers anyways.
Bandwidth and server costs?.. yes, they are costs that BK would have to bear, but I doubt very much that it comes to anywhere near the half a mil a year quoted.
Let's look at what BK gained from the deal:-
They got massive and public prof that the system did what it was supposed to and worked well at this scale - how many other projects (OS or proprietary) as large would use it and allow BK to say they were using it?
Massive, massive, huge unspeakable amounts of good publicity - it went from a fairly niche product to something that every linux hacker has discussed overnight!
I would imagine a large number of big customers would have moved to BK purely for those two points alone.
The ideal solution would've been for the 'troublemaker' to leave the group
That makes no sense at all.
Tridge should leave what group, exactly?
The group of BK users - that he wasn't a part of anyway? - or the OSS group? "sorry mate, that guy over there doesn't like the look of you, so you will have to give up your hobby. Stop coding now and stop giving stuff away"
People should select SCM software based on technical merits and user productivity rather than religious views on licensing
You do realise thatthe entire foundation, the whole point, the differentiator of open source software is licensing. The license issue is a hugely important issue, otherwise Linux would not have made it much further past Linus' initial realease. Those people with the skill enough and cared enough to want software with user-friendly licenses picked it up and helped along to bring things where they are - if you don't get the licensing point, you simply do not get open source software.
Where Bill says that he prefers the BSD license to the GPL, he is talking about other people's code. Basically, with the BSD licence, code can be ripped out of a project and used within their own closed products. Such as what apparently happened with parts of the NT IP protocol stack
If they tried that with the Linux IP stack, they would have to put the rest of the nT kernel under GPL - that's what's wrong with GPL, he can't make money off other people's work without giving something back in return.
Dammit.. I was hopeing that this would mean I could sue them every time installig one of their brain-dead OS's into an empty partition destroyed the data in the MBR, thus making the system unusbale , and a PITA to fix.
Then I remembered I've never even attempted to run it on my machines for five years+.. oh well.
I was initially disappointed with the performance of my Athlon64. CPU intensive 64bit code often seemed much slower than it's (heavily optimised) 32bit counterpart.
Every now & then I come across some code optimised for 64bit processors, and it just flies - as more & more stuff gets the treatment, it will be like upgradingin for free:)
Doesn't matter, the fact is that there are collisions in MD-5, SHA-1 and any other hashing algorithm you care to mention. The 'goodness' of a hash is represented by howwell distributed results are among the hash-space. If you have 'clumps' of results, then you have a bad algorithm - I don't think that this hasd been demonstrated in MD5 yet.
Demonstrating a single collision, or a couple of manufactured collisions is not an issue. You can get worried if someone can produce a match for arbitrary data on request.
I should patent my own hash function that's guarranteed to not have any collisions - maybe that will make you feel safer? I've called it 'NULL', by the way;)
When BB's license became too restrictive for me, I couldn't determine whether what we were doing with it required spending hundreds on the commercial license or not, I loosed myself;) from my ties with BB and chose another package.
Tis a shame really, as I hjad written several BB plugins and ran (with the author's blessing) an archive site of client binaries for various platforms.
'Stealth' iis useful for system security for the simple reason that it causes serious delays for many potential attackers. A full-range portscan against a machine returning ACK/RST or ICMP-Port-Unreachable is far faster than having to rely on timeouts and multiple attempts to differentiate between a 'stealthed' port and random network trouble.
When this is applied to a firewall protecting a network of machines, then it's even more useful as you cannot be certain what is there and what isn't.
I don't care if it breaks the RFCs in this case. For services that should be available, but are somehow broken will get the correct error response, so legitimate users will not be inconvenienced. The only systems sending diagnostic requests (pings etc.) are allowed to do that by the firewall.
I've never used Windows Firewall (or XP or that matter), but their port scanning results look inconsistent to me.
There should not be such a difference between the TCP Connect scan and the TCP SYN scan.
I want to cover a few definitaions that aren't in the article. If they are using different definitions for these terms, they are going to confuse a lot of people (and may be confused themselves).
'Stealthed' port - yeuch, I don't like that name, but I assume that is where a probe to a port illicits no response from the remote host
'Closed' port - where the host returns the correct 'not available' response. In the case of TCP, this is a packet with the ACK and RST flags set.
'Connect Scan' - A port-scan that performs the full TCP three phase TCP connection handshake. Usually only performed when you don't have rights to perform a SYN scan.
'SYN Scan' - A port scan that only sends the initial SYN packet of the TCP handshake and bases it's result on the response.
For the 'Connect' scan, the tester will have sent a 'SYN' packet to the port being tested. The 'Stealthed' ports will have sent back no response at all. The 'Closed' ports will have sent back an ACK/RST packet.
For the 'SYN' scan, the tester will have sent a 'SYN' packet to the port being tested. The 'Stealthed' ports will have sent back no response at all. At this point, the 'SYN' scan is identical to the 'Connect' scan, so the 'closed' ports should have sent back ACK/RST.
This leads me to believe that either the testers system was broken, the target system firewall was in a different state during the SYN scan, or there is something really weird going on there.
As for the 'Turning Off' claim, that appears to be when the user or process has admin rights. As with the ludicrous Trend Anti-Virus 'vulnerability' posted to Bugtraq last week, it's unreasonable to expect software to 'defend' against being reconfigured or turned off by an authorised administrator.
There's two ways of looking at the biometrics/card system, and both have their flaws...
It depends on wether the biometric information 'unlocks' the identifying information on the card (like a PIN for an ATM card), or wether the card provides biometric information that is then compared to you, in order to prove who you are.
In the first case, the card acts as the authentication credentials and so can be revoked and replaced. However, any replacement is unlocked by the same biometric data which has already been compromised. In which case, the card may as well be left unprotected.
The second option is effectively what I was describing in the earlier posts. Either way, the use of biometrics in this context introduces security concerns.
Yeah, the technology may be able to change to deal with a new way of fooling the existing tech.
Let's step back a bit and look at the two things needed for an authentication system...
1. Input device - the means to input the credentials into the system. These include fingerprint scanners, and keyboards for passwords etc.
2. Credentials - Fingerprints, passwords, one-time codes etc.
Traditionally, every outhentication credential can be copied or stolen eventually. So, if someone learns your password or steals your smartcard, then the sysadmin can disable it and issue a new one. Who wants to be the first volunteer to be issued with new fingerprints?
Oh yes, the technology will evolve to be able to detect a new method of faking 'prints, but this will involve replacing or upgrading every authentication terminal in use, a hugely expensive task - a sign of a fundamentally broken idea if you ask me.
The Tesco chain of supermarkets over the English side of the pond are having great success with Internet grocery shopping. They have a good percentage of the country covered by the service (but not where I live:-\)
Well, hardware is the only thing MS are really good at.. their mice, game controllers & keyboards are second only to Logitech IMO... I must find out if their software is of similar quality one day;)
Err... correct me if I'm wrong, but wasn't AutoCAD originally purely (or, at least mainly) command-line driven??
I've never used it myself (not being an architect or anything, Gimp more than does for my yearning to scribble), but I seem to remember a friend of mine (who does use it) moaning bout the newer versions and how he always turns off the icons 'and other sh*t'
The last couple of weeks has demonstrated precisley what is wrong, from an end-user standpoint, with 'responsible disclosure' (yeuch!)
I don't know why, but ISS seemed to get under the skin of a lot of security researchers with their release of details of the recent Apache problem. This release was *directly responsible* for someone (I forget who, but thanks are due) to code a fairly simple work-around in the form of an Apache module, so that people can quickly install some protection whilst waiting for a fix to appear, and ancilliary apache addons (modssl, php etc.) to catch up with the new Apache release, so we are now maore-or-less protected whilst compiling, testing and installing new versiona of about half a dozen bits of software. Because of this release, the problem can be handled in a calm and non-disruptive manner.
Oh, and someone reported being hit with similar symptoms to this problem, well before ISS released the details.
Take that in contrast to when this OpenSSH problem hit the net. I was well aware of OpenSSH 3.3 and the new security features, and had a plan to wait till the next release (to check for implementation problems) and then upgrade all our servers in an orderly manner.
However,this morning, I opened Bugtraq to find a load of peeps that should know better (i.e. OpenSSH developers) screaming that there was a major root-exploit in the code I was currently running, that I had to upgrade immidiately, and no, they won't tell me what the problem is. Based on the available information, I made a judgement call, and suspended all incoming ssh access at the firewall until I could upgrade. As you can imagine, this pissed off a lot of customers. I also had to then reschedule my day to get, test and install this new version of SSH - I did not have time to put it through our usual QA process - to get us operational again.
To add insult to injury, when the details were released, it turns out to be a problem with a feature we do not even use and a simple config change was a suitable work-around.
Who do I get to bill for our (useless) 3 hour downtime?
When I flew to the states a few months back, there were a selction of Gameboy colour games that passenegrs could play to relieve the boredom. The machines that these run on are actually PCs, and the words 'Copyright Nintendo' were clearly visible on a text mode screen for a fraction of a second as the emulator loaded.
Because it isn't a human. Wget is a fantastic utility, but when used with -r, it is a robot.
robots.txt isn't just used to stop search engines indexing confidential information, it can also used to prevent robots from falling into things that they can't get out of. This can range from intentional tarpits to some genuine CGIs.
I very much doubt it.
Different systems have different requirements in packages. At a minimum
Processor & architecture for binaries
Filesystem layout
Configuration requirements for related software (not everywhere, for instance uses the same inetd.conf format)
Dependancies on libraries
Naming conventions for packages
etc..etc..etc..
I hate to be a pessimist (OK, that's probably a lie;) but, as you would still need individual packages for almost every platform, I don't see what the big deal about this is?
The only thing I can see being good about it is on systems where you don't have a vendor supported pacakging system as good as RPM. But, if it's purely for functionality, why not just port apt?
OK, that is evidence. Thanks for point ing that out to me.
The point I was making was that the article on the bbc news did not make any mention of any reasons for the crash.
Quotes from the linked site:
"First reports indicate that human error is to blame for the crash, a German railways spokesman has been quoted as saying."
and
"Police have yet to determine why the two trains were travelling in opposite directions on the same line."
It has become far too common recently for people to immediately blame things on Islamic Militants as a knee-jerk reaction.
My thoughts are with those who are injured - I hope there are no fatalities.
Slashdot Mirror
I've still got a PMP-300 :P
:D
It's got a problem with the battery clip, but apart from that is fine
It's not .. quote .. like that.
.. everything revolves around the numbers.
The problem with advertising based revenue, or 'subscriber-choice' based revenue is simple
The 'experts' can happily say that show a will attract x million viewers because it fits into the same mould as another show that got a similar number of viewers, whereas with show b - which is a completely original affair, or a departure from the current norm - they have no idea, no frame of reference to say that it is going to make so many millions in revenue. Most companies will therefore stick with the same-old same-old tried and tested variants of Big Brother.
Organisations like the BBC have extra freedom to experiment somewhat, and therefore do a lot of quality non-mainstream programmes (I presume that many of the ones I don't like have a quality an purity of their own) including a hell of a lot of excellent stuff that would very rarely even be attempted elsewhere - things like Monty Python, Dr. Who, Neverwhere, HHGTTG, Hustle, Red Dwarf, Blackadder, Little Britain to name but a few. They are encouraged to 'push the envelope' rather than chase ratings.
Sure, there are some notable experiments in the ratings sector (Ultraviolet, 24 and BSG spring to mind), but these are relatively few and far between in comparison to the BBC's gems.
I'm happy to shell out my hard-earned for a situation that engenders creative programming.
[blockquote]the film is every bit as much a loving tribute to Douglas Adams as it is a joyous comedy.[/blockquote]
so, it's as funny as a funeral and bears no resemblance to the book then?
How was it costing them that much? Such figures are just like the IRAA's 'cost of piracy' figures - pure Bull.
Look at the 'cost'..
- is it costing BK the value of the licenses?
.. No. That's revenue that they could have gained if the kernel developers chose to buy it independantly
- is it the cost of developing bug-fixes?
.. don't make me laugh - they have to do that anyways.
- Is is the cost of implementing features necessary for a huge distributed development team?
.. considering that this is precisely what BK was designed for, a large amount of such improvements would be required or requested by their paying customers anyways.
- Bandwidth and server costs?
.. yes, they are costs that BK would have to bear, but I doubt very much that it comes to anywhere near the half a mil a year quoted.
Let's look at what BK gained from the deal- They got massive and public prof that the system did what it was supposed to and worked well at this scale - how many other projects (OS or proprietary) as large would use it and allow BK to say they were using it?
- Massive, massive, huge unspeakable amounts of good publicity - it went from a fairly niche product to something that every linux hacker has discussed overnight!
- I would imagine a large number of big customers would have moved to BK purely for those two points alone.
That makes no sense at all.Tridge should leave what group, exactly?
The group of BK users - that he wasn't a part of anyway? - or the OSS group? "sorry mate, that guy over there doesn't like the look of you, so you will have to give up your hobby. Stop coding now and stop giving stuff away"
You do realise thatthe entire foundation, the whole point, the differentiator of open source software is licensing. The license issue is a hugely important issue, otherwise Linux would not have made it much further past Linus' initial realease. Those people with the skill enough and cared enough to want software with user-friendly licenses picked it up and helped along to bring things where they are - if you don't get the licensing point, you simply do not get open source software.
Where Bill says that he prefers the BSD license to the GPL, he is talking about other people's code. Basically, with the BSD licence, code can be ripped out of a project and used within their own closed products. Such as what apparently happened with parts of the NT IP protocol stack
If they tried that with the Linux IP stack, they would have to put the rest of the nT kernel under GPL - that's what's wrong with GPL, he can't make money off other people's work without giving something back in return.
Dammit .. I was hopeing that this would mean I could sue them every time installig one of their brain-dead OS's into an empty partition destroyed the data in the MBR, thus making the system unusbale , and a PITA to fix.
.. oh well.
Then I remembered I've never even attempted to run it on my machines for five years+
I'm shocjed that this has been on /. so long yet no-one on the main page mentions the 'L' word :o
I was initially disappointed with the performance of my Athlon64. CPU intensive 64bit code often seemed much slower than it's (heavily optimised) 32bit counterpart.
:)
Every now & then I come across some code optimised for 64bit processors, and it just flies - as more & more stuff gets the treatment, it will be like upgradingin for free
Doesn't matter, the fact is that there are collisions in MD-5, SHA-1 and any other hashing algorithm you care to mention. The 'goodness' of a hash is represented by howwell distributed results are among the hash-space. If you have 'clumps' of results, then you have a bad algorithm - I don't think that this hasd been demonstrated in MD5 yet.
;)
Demonstrating a single collision, or a couple of manufactured collisions is not an issue. You can get worried if someone can produce a match for arbitrary data on request.
I should patent my own hash function that's guarranteed to not have any collisions - maybe that will make you feel safer? I've called it 'NULL', by the way
When BB's license became too restrictive for me, I couldn't determine whether what we were doing with it required spending hundreds on the commercial license or not, I loosed myself ;) from my ties with BB and chose another package.
Tis a shame really, as I hjad written several BB plugins and ran (with the author's blessing) an archive site of client binaries for various platforms.
'Stealth' iis useful for system security for the simple reason that it causes serious delays for many potential attackers. A full-range portscan against a machine returning ACK/RST or ICMP-Port-Unreachable is far faster than having to rely on timeouts and multiple attempts to differentiate between a 'stealthed' port and random network trouble.
When this is applied to a firewall protecting a network of machines, then it's even more useful as you cannot be certain what is there and what isn't.
I don't care if it breaks the RFCs in this case. For services that should be available, but are somehow broken will get the correct error response, so legitimate users will not be inconvenienced. The only systems sending diagnostic requests (pings etc.) are allowed to do that by the firewall.
I want to cover a few definitaions that aren't in the article. If they are using different definitions for these terms, they are going to confuse a lot of people (and may be confused themselves).
For the 'Connect' scan, the tester will have sent a 'SYN' packet to the port being tested. The 'Stealthed' ports will have sent back no response at all. The 'Closed' ports will have sent back an ACK/RST packet.
For the 'SYN' scan, the tester will have sent a 'SYN' packet to the port being tested. The 'Stealthed' ports will have sent back no response at all. At this point, the 'SYN' scan is identical to the 'Connect' scan, so the 'closed' ports should have sent back ACK/RST.
This leads me to believe that either the testers system was broken, the target system firewall was in a different state during the SYN scan, or there is something really weird going on there.
As for the 'Turning Off' claim, that appears to be when the user or process has admin rights. As with the ludicrous Trend Anti-Virus 'vulnerability' posted to Bugtraq last week, it's unreasonable to expect software to 'defend' against being reconfigured or turned off by an authorised administrator.
I've just realised I'm defending M$ here
There's two ways of looking at the biometrics/card system, and both have their flaws...
It depends on wether the biometric information 'unlocks' the identifying information on the card (like a PIN for an ATM card), or wether the card provides biometric information that is then compared to you, in order to prove who you are.
In the first case, the card acts as the authentication credentials and so can be revoked and replaced. However, any replacement is unlocked by the same biometric data which has already been compromised. In which case, the card may as well be left unprotected.
The second option is effectively what I was describing in the earlier posts. Either way, the use of biometrics in this context introduces security concerns.
Yeah, the technology may be able to change to deal with a new way of fooling the existing tech.
Let's step back a bit and look at the two things needed for an authentication system...
1. Input device - the means to input the credentials into the system. These include fingerprint scanners, and keyboards for passwords etc.
2. Credentials - Fingerprints, passwords, one-time codes etc.
Traditionally, every outhentication credential can be copied or stolen eventually. So, if someone learns your password or steals your smartcard, then the sysadmin can disable it and issue a new one.
Who wants to be the first volunteer to be issued with new fingerprints?
Oh yes, the technology will evolve to be able to detect a new method of faking 'prints, but this will involve replacing or upgrading every authentication terminal in use, a hugely expensive task - a sign of a fundamentally broken idea if you ask me.
The Tesco chain of supermarkets over the English side of the pond are having great success with Internet grocery shopping. They have a good percentage of the country covered by the service (but not where I live :-\)
http://www.tesco.co.uk/
Well, hardware is the only thing MS are really good at .. their mice, game controllers & keyboards are second only to Logitech IMO... I must find out if their software is of similar quality one day ;)
Heh ... I've forgotten how many of the TGLCT threads we got though before I got bored of waiting for the game.. 13? 14?
Did you see the BBC's TV version of it .. fatastic. All of the low-budget goodness and inventivness that made Dr. Who great :)
Err... correct me if I'm wrong, but wasn't AutoCAD originally purely (or, at least mainly) command-line driven??
I've never used it myself (not being an architect or anything, Gimp more than does for my yearning to scribble), but I seem to remember a friend of mine (who does use it) moaning bout the newer versions and how he always turns off the icons 'and other sh*t'
I don't know why, but ISS seemed to get under the skin of a lot of security researchers with their release of details of the recent Apache problem. This release was *directly responsible* for someone (I forget who, but thanks are due) to code a fairly simple work-around in the form of an Apache module, so that people can quickly install some protection whilst waiting for a fix to appear, and ancilliary apache addons (modssl, php etc.) to catch up with the new Apache release, so we are now maore-or-less protected whilst compiling, testing and installing new versiona of about half a dozen bits of software. Because of this release, the problem can be handled in a calm and non-disruptive manner.
Oh, and someone reported being hit with similar symptoms to this problem, well before ISS released the details.
Take that in contrast to when this OpenSSH problem hit the net. I was well aware of OpenSSH 3.3 and the new security features, and had a plan to wait till the next release (to check for implementation problems) and then upgrade all our servers in an orderly manner.
However,this morning, I opened Bugtraq to find a load of peeps that should know better (i.e. OpenSSH developers) screaming that there was a major root-exploit in the code I was currently running, that I had to upgrade immidiately, and no, they won't tell me what the problem is. Based on the available information, I made a judgement call, and suspended all incoming ssh access at the firewall until I could upgrade. As you can imagine, this pissed off a lot of customers. I also had to then reschedule my day to get, test and install this new version of SSH - I did not have time to put it through our usual QA process - to get us operational again.
To add insult to injury, when the details were released, it turns out to be a problem with a feature we do not even use and a simple config change was a suitable work-around.
Who do I get to bill for our (useless) 3 hour downtime?
When I flew to the states a few months back, there were a selction of Gameboy colour games that passenegrs could play to relieve the boredom. The machines that these run on are actually PCs, and the words 'Copyright Nintendo' were clearly visible on a text mode screen for a fraction of a second as the emulator loaded.
Because it isn't a human. Wget is a fantastic utility, but when used with -r, it is a robot.
robots.txt isn't just used to stop search engines indexing confidential information, it can also used to prevent robots from falling into things that they can't get out of. This can range from intentional tarpits to some genuine CGIs.
Different systems have different requirements in packages. At a minimum
- Processor & architecture for binaries
- Filesystem layout
- Configuration requirements for related software (not everywhere, for instance uses the same inetd.conf format)
- Dependancies on libraries
- Naming conventions for packages
- etc..etc..etc..
I hate to be a pessimist (OK, that's probably a lieThe only thing I can see being good about it is on systems where you don't have a vendor supported pacakging system as good as RPM. But, if it's purely for functionality, why not just port apt?
OK, that is evidence. Thanks for point ing that out to me.
The point I was making was that the article on the bbc news did not make any mention of any reasons for the crash.
Quotes from the linked site:
"First reports indicate that human error is to blame for the crash, a German railways spokesman has been quoted as saying."
and
"Police have yet to determine why the two trains were travelling in opposite directions on the same line."
It has become far too common recently for people to immediately blame things on Islamic Militants as a knee-jerk reaction.
My thoughts are with those who are injured - I hope there are no fatalities.
It doesn't mention anywhere in the news article about why the trains crashed.
It is stupid, childish and above all dangerous to just blame any accident or incident on 'Islamic extremists'.
Whay can't people look at the facts before pointing fingers anymore?