Escrow would only be helpful if these companies were offering proprietary products - some of them may be, but many are not. They are offering access to applications which the out-sourcing company could either not afford to pay full whack for as they're only using it from time to time (maybe a major accounting package) or applications which the companies don't want to spend the time and money learning how to administer. These two cases are about access to available applications in a new way, not about access to new applications.
Microsoft, don't forget, is going with a licensing model that is likely to help the ASP model - you license for use, but that doesn't mean that you hold the software yourself - why not get someone else to look after it for you?
My general feeling is that there is a lot to be said for an ASP-like model. If I have 20 people out of 2000 using a complicated ERP package, for instance, why should I have 2 or 3 of my IT support staff learning all about it so that they can support it all the hours of the day? It may be mission critical, but if I can find someone else to provide access to it, and not have to worry about training for support, then that's got to be a good thing. The problem seems to be that either the market isn't ready, or the model isn't mature enough. Maybe the applications don't suit the deployment model.
What's more, given the discussion about tech support on/. yesterday, maybe this is a good model for OSS applications - you don't need to train too many people to support the software, you just need them available from a central point.
ASP, then, isn't by definition a Bad Thing[tm] - but it may not yet be a Ready Thing for everybody. We seem ready to accept managed hosting - before we sentence the ASP model, let's think around it in more detail.
What does tech support mean in an OSS world? Standing behind a product which you create, yes - but what if you didn't create it? There is certainly the opportunity to build a support business behind OSS products, but it's more difficult than you might think - look at LinuxCare and it's problems.
The "community" isn't enough for many enterprises and organisations, either. They need to be sure that they've got 24x7 access to tech support for the applications (and OSes) that they rely on, and until we have a robust model for providing that support, it's one area that will continue to hold back take-up of OSS software. None of the models we see at the moment see to provide enough yet: Linuxcare and their ilk are having difficulties (maybe because they cast their net too wide, and didn't concentrate on particular apps), IRC and web-based guru services aren't going to convince large businesses. The Sendmail model is an interesting one, but what about scalability? Could it handle Evolution, for instance, when that goes 1.0?
I think that this is an issue which we, as a community, really need to address.
I find it hard not to agree with the tenor of the article, but would offer one caveat: wait. Maybe we _are_ developing a virtual community, slowly, but I wonder how true that is of China? More importantly, how much does the virtual community span over into China? How many Chinese readers are there of slashdot, for instance?
I'm British, and feel part of a number of virtual communities. If (heaven forbid), something similar happened between the UK and the US, then I think we might find the virtual community putting pressure on our leaders to do something sensible about the mess. You can't, however, expect a strong virtual community across national borders yet, particularly across the East/West divide, where modes of communication are different, and levels access to developing communities varies significantly.
Most important decision for RH?
on
Ask Robert Young
·
· Score: 4
What was the most important decision for Red Hat, through its history, apart from deciding to IPO? Was there a particular partnership, hire, technical call or anything else which defined the future for Red Hat?
The question will be, I suspect, how well Palm OS variants react to the competition that's going to arise from EPOC 6.0 and what the take-up will be of the OS in the new 3G devices. The mobile providers have invested so much in buying the new licenses that they have to make the applications work, so if Palm lags behind the EPOC folks, then it's the EPOC apps which are going to get the development money.
What I find interesting about the Sim "games" is the meta-realistic aspect of the game-play. The assumption that you can take a fully objective view of a situation, at the same time influencing the "characters" in the game, should be making us think.
The excellent "Simulation of Surveillance" by William Bogard (Cambridge University Press, 1996, ISBN 0521555612) examines some of the issues around what it means to stand "outside" a situation, and have a "god-like" view of what's going on. Of course, in the Sim-type games, the models of interaction are somewhat hidden from us, and randomised, so that the characters enjoy some free-will, but certainly less than in real-life. I'd be interested to know of any academic work going on which looks either at comparing players of these games with "surveillers" - prison wardens, CCTV operators, etc. - or at the modelling process.
The US is at an advantage here, and good on them. In the UK (and many other countries), unmetered phone access (even for local numbers) is a dream, and far from a reality. People can't afford to spend a long time online, as their phone bills go through the roof. BT (our main phone operator) is offering unmetered local & Internet calls in the evening and at weekends for a flat rate of (I think) £4.99 a quarter (around $7.30), but this still isn't good enough to get everybody online.
I don't think that Swedish Chef would be a good one - neither would Jive, etc. - for the simple reason that it's almost certainly lossy "encryption", in the same sense that jpeg is a lossy encoding - you lose information when you use it. You'd not be certain that you could get back to the original title. I'm sure that the scheme they're using is non-lossy - though we might need them to certify that, as we're not in a position to reverse engineer it ourselves.
Right - I've just looked at all the discussion on/., and I'm going to post another comment, and it's a congratulation. Well done, Aimster.
We all know that this isn't really going to make anyone safer, or stop the RIAA doing anything. In fact, I doubt that Aimster really care how much they upset the RIAA, or if the RIAA care themselves. My suspicion is that it's a publicity play. Getting your users (and/. is _right_ in the middle of their target audience) to see new things isn't always easy, so - time to generate some free publicity. And it's worked. People are debating the rights and wrongs of their (pretty specious, I suspect) argument, they're getting thousands of hits from/., and lots of links from the news agencies, probably.
Which is what they wanted. Nice work - you've got your users covered, you've made RIAA spend some money on _really_ checking with their lawyers, just in case, and you've raised your profile outside your user network, too. I rather like it!
This is funny - it had me laughing out loud - but I do have a few concerns about using legislation of which we don't approve in order to beat the nasty people round the head. Would Aimster react positively or negatively to someone producing an Open Source reverse-engineered piece of sofware for doing this? What if the RIAA did it themselves? Is this substantively different to DeCSS?
So, it's funny, and it's parodying the whole mess, but let's be careful, now. Do we see ESR writing closed source code to get back at M$? No, we don't...
PKI is one of those really hot topics that we're all going to have to come to terms with if we really believe things like Open Source, distributed processing, trust networks and P2P. In order to be in a position to trust other people, we're going to have to be pretty sure that we know who they are, and without PKI, this gets difficult when you go really large-scale.
Consider - it's all very well deciding that I trust ESR to play with my code, or run cycles on my machine, because he's so well known, and his identity so well verifiable, that I can be pretty sure it's him doing it. But if I'm running a big distributed system, and you don't know me - how are you going to be sure it's me that's putting code on your machine? With PKI. In fact, I probably wouldn't trust an entity claiming to be ESR without third-party certification such as can be provided via PKI.
For P2P, you want to be sure who you're talking to (remember the story earlier this week about Windows shares? Well, maybe some people _want_ to allow some other people access, but need to be really sure who's there). For distributed processing, you want to make sure it _is_ SETI, and not a criminal key-cracking syndicate. For Open Source, you might want to run a trust network to decide who gets to release code.
PKI is important because trust is important, and because encryption is _hard_ to do in a scaleable, trusting way without it. Time to get learning about this, everyone.
We finally seem to be getting down to a decent size for planet exploration. Harden them up a bit, and drop them over a terrain. They shouldn't need much cushioning, as they'll weigh very little.
Give them a single burst radio broadcasting capability, so they can report back, and you're away. Cheap, light, low volume - how many can you fit in a Mars probe? This should be great way of exploring new habitats.
One alternative to just dropping them is to land, and then spew them out - that way you get a lot more detailed information about a small area, and can control them so that if one of them finds something interesting, they can all go and investigate. Next step, of course, is to allow them to collaborate, and decide to do it themselves.
Re:Don't read this book - Write some code.
on
Rebel Code
·
· Score: 1
Going hell for leather isn't always a good thing, even if the paradigm which you're following is working well. There are times when it helps to step back and think about how it's working, and maybe have a stab at improving it.
You'll get it wrong sometimes, and that's good - innovation's like that - but from time to time, a new model will come about. Having a good hard think about why OS works - as ESR did with The Cathedral and the Bazaar - can be productive in itself, and can work for hackers, not just management types.
Re:Don't read this book - Write some code.
on
Rebel Code
·
· Score: 1
IMHO, there's a lot of point to this sort of book. Not everyone is a hacker, not everyone should be. But good history and theory can help record and legitimise a movement, and help the movement to evolve, as it surely will.
We need to get not only the hackers believing, but the press, the public, and, possibly most important, managers and corporates. We've seen recent stories about restrictive terms and conditions of employment, which basically stop people contributing to the Open Source movement. If we can educate managers and organisations, then maybe they (we, I) can be convinced that OSS is a good thing, and not just Open Source Software, openness (freeness) in other fields of endeavour as well.
The model for mobile phones in Japan is pretty different to that in the US & Europe, as I understand it, in that most cells are small - a block or so - I wonder how this affects the opportunities, and how it plays on bandwidth.
There are some new technologies coming out at the moment to provide smaller cells for better (and broader-band) access within GSM, but I'm not qualified to talk about them. How will this affect take up outside Japan?
I was visiting the HP facility in Cupertino last summer when the temperature starting hitting 115F, and the demand from air conditioning units was just too great. What I hadn't realised was that major power consumers (like HP) get maybe 15-30 minutes warning, and the chance to close things down. There's clearly a protocol within HP as to how to deal with this, as only a few people were running round like lunatics shutting things down. Most people were turning off their workstations and wondering if they should just head off a couple of hours only, particularly those in cubicles some way from natural light.
Slashdot Mirror
Escrow would only be helpful if these companies were offering proprietary products - some of them may be, but many are not. They are offering access to applications which the out-sourcing company could either not afford to pay full whack for as they're only using it from time to time (maybe a major accounting package) or applications which the companies don't want to spend the time and money learning how to administer. These two cases are about access to available applications in a new way, not about access to new applications.
/. yesterday, maybe this is a good model for OSS applications - you don't need to train too many people to support the software, you just need them available from a central point.
Microsoft, don't forget, is going with a licensing model that is likely to help the ASP model - you license for use, but that doesn't mean that you hold the software yourself - why not get someone else to look after it for you?
My general feeling is that there is a lot to be said for an ASP-like model. If I have 20 people out of 2000 using a complicated ERP package, for instance, why should I have 2 or 3 of my IT support staff learning all about it so that they can support it all the hours of the day? It may be mission critical, but if I can find someone else to provide access to it, and not have to worry about training for support, then that's got to be a good thing. The problem seems to be that either the market isn't ready, or the model isn't mature enough. Maybe the applications don't suit the deployment model.
What's more, given the discussion about tech support on
ASP, then, isn't by definition a Bad Thing[tm] - but it may not yet be a Ready Thing for everybody. We seem ready to accept managed hosting - before we sentence the ASP model, let's think around it in more detail.
What does tech support mean in an OSS world? Standing behind a product which you create, yes - but what if you didn't create it? There is certainly the opportunity to build a support business behind OSS products, but it's more difficult than you might think - look at LinuxCare and it's problems.
The "community" isn't enough for many enterprises and organisations, either. They need to be sure that they've got 24x7 access to tech support for the applications (and OSes) that they rely on, and until we have a robust model for providing that support, it's one area that will continue to hold back take-up of OSS software. None of the models we see at the moment see to provide enough yet: Linuxcare and their ilk are having difficulties (maybe because they cast their net too wide, and didn't concentrate on particular apps), IRC and web-based guru services aren't going to convince large businesses. The Sendmail model is an interesting one, but what about scalability? Could it handle Evolution, for instance, when that goes 1.0?
I think that this is an issue which we, as a community, really need to address.
I find it hard not to agree with the tenor of the article, but would offer one caveat: wait. Maybe we _are_ developing a virtual community, slowly, but I wonder how true that is of China? More importantly, how much does the virtual community span over into China? How many Chinese readers are there of slashdot, for instance?
I'm British, and feel part of a number of virtual communities. If (heaven forbid), something similar happened between the UK and the US, then I think we might find the virtual community putting pressure on our leaders to do something sensible about the mess. You can't, however, expect a strong virtual community across national borders yet, particularly across the East/West divide, where modes of communication are different, and levels access to developing communities varies significantly.
What was the most important decision for Red Hat, through its history, apart from deciding to IPO? Was there a particular partnership, hire, technical call or anything else which defined the future for Red Hat?
The question will be, I suspect, how well Palm OS variants react to the competition that's going to arise from EPOC 6.0 and what the take-up will be of the OS in the new 3G devices. The mobile providers have invested so much in buying the new licenses that they have to make the applications work, so if Palm lags behind the EPOC folks, then it's the EPOC apps which are going to get the development money.
What I find interesting about the Sim "games" is the meta-realistic aspect of the game-play. The assumption that you can take a fully objective view of a situation, at the same time influencing the "characters" in the game, should be making us think.
The excellent "Simulation of Surveillance" by William Bogard (Cambridge University Press, 1996, ISBN 0521555612) examines some of the issues around what it means to stand "outside" a situation, and have a "god-like" view of what's going on. Of course, in the Sim-type games, the models of interaction are somewhat hidden from us, and randomised, so that the characters enjoy some free-will, but certainly less than in real-life. I'd be interested to know of any academic work going on which looks either at comparing players of these games with "surveillers" - prison wardens, CCTV operators, etc. - or at the modelling process.
The US is at an advantage here, and good on them. In the UK (and many other countries), unmetered phone access (even for local numbers) is a dream, and far from a reality. People can't afford to spend a long time online, as their phone bills go through the roof. BT (our main phone operator) is offering unmetered local & Internet calls in the evening and at weekends for a flat rate of (I think) £4.99 a quarter (around $7.30), but this still isn't good enough to get everybody online.
I don't think that Swedish Chef would be a good one - neither would Jive, etc. - for the simple reason that it's almost certainly lossy "encryption", in the same sense that jpeg is a lossy encoding - you lose information when you use it. You'd not be certain that you could get back to the original title. I'm sure that the scheme they're using is non-lossy - though we might need them to certify that, as we're not in a position to reverse engineer it ourselves.
Right - I've just looked at all the discussion on /., and I'm going to post another comment, and it's a congratulation. Well done, Aimster.
/. is _right_ in the middle of their target audience) to see new things isn't always easy, so - time to generate some free publicity. And it's worked. People are debating the rights and wrongs of their (pretty specious, I suspect) argument, they're getting thousands of hits from /., and lots of links from the news agencies, probably.
We all know that this isn't really going to make anyone safer, or stop the RIAA doing anything. In fact, I doubt that Aimster really care how much they upset the RIAA, or if the RIAA care themselves. My suspicion is that it's a publicity play. Getting your users (and
Which is what they wanted. Nice work - you've got your users covered, you've made RIAA spend some money on _really_ checking with their lawyers, just in case, and you've raised your profile outside your user network, too. I rather like it!
This is funny - it had me laughing out loud - but I do have a few concerns about using legislation of which we don't approve in order to beat the nasty people round the head. Would Aimster react positively or negatively to someone producing an Open Source reverse-engineered piece of sofware for doing this? What if the RIAA did it themselves? Is this substantively different to DeCSS?
So, it's funny, and it's parodying the whole mess, but let's be careful, now. Do we see ESR writing closed source code to get back at M$? No, we don't...
PKI is one of those really hot topics that we're all going to have to come to terms with if we really believe things like Open Source, distributed processing, trust networks and P2P. In order to be in a position to trust other people, we're going to have to be pretty sure that we know who they are, and without PKI, this gets difficult when you go really large-scale.
Consider - it's all very well deciding that I trust ESR to play with my code, or run cycles on my machine, because he's so well known, and his identity so well verifiable, that I can be pretty sure it's him doing it. But if I'm running a big distributed system, and you don't know me - how are you going to be sure it's me that's putting code on your machine? With PKI. In fact, I probably wouldn't trust an entity claiming to be ESR without third-party certification such as can be provided via PKI.
For P2P, you want to be sure who you're talking to (remember the story earlier this week about Windows shares? Well, maybe some people _want_ to allow some other people access, but need to be really sure who's there). For distributed processing, you want to make sure it _is_ SETI, and not a criminal key-cracking syndicate. For Open Source, you might want to run a trust network to decide who gets to release code.
PKI is important because trust is important, and because encryption is _hard_ to do in a scaleable, trusting way without it. Time to get learning about this, everyone.
We finally seem to be getting down to a decent size for planet exploration. Harden them up a bit, and drop them over a terrain. They shouldn't need much cushioning, as they'll weigh very little.
Give them a single burst radio broadcasting capability, so they can report back, and you're away. Cheap, light, low volume - how many can you fit in a Mars probe? This should be great way of exploring new habitats.
One alternative to just dropping them is to land, and then spew them out - that way you get a lot more detailed information about a small area, and can control them so that if one of them finds something interesting, they can all go and investigate. Next step, of course, is to allow them to collaborate, and decide to do it themselves.
Going hell for leather isn't always a good thing, even if the paradigm which you're following is working well. There are times when it helps to step back and think about how it's working, and maybe have a stab at improving it.
You'll get it wrong sometimes, and that's good - innovation's like that - but from time to time, a new model will come about. Having a good hard think about why OS works - as ESR did with The Cathedral and the Bazaar - can be productive in itself, and can work for hackers, not just management types.
IMHO, there's a lot of point to this sort of book. Not everyone is a hacker, not everyone should be. But good history and theory can help record and legitimise a movement, and help the movement to evolve, as it surely will.
We need to get not only the hackers believing, but the press, the public, and, possibly most important, managers and corporates. We've seen recent stories about restrictive terms and conditions of employment, which basically stop people contributing to the Open Source movement. If we can educate managers and organisations, then maybe they (we, I) can be convinced that OSS is a good thing, and not just Open Source Software, openness (freeness) in other fields of endeavour as well.
The model for mobile phones in Japan is pretty different to that in the US & Europe, as I understand it, in that most cells are small - a block or so - I wonder how this affects the opportunities, and how it plays on bandwidth.
There are some new technologies coming out at the moment to provide smaller cells for better (and broader-band) access within GSM, but I'm not qualified to talk about them. How will this affect take up outside Japan?
I was visiting the HP facility in Cupertino last summer when the temperature starting hitting 115F, and the demand from air conditioning units was just too great. What I hadn't realised was that major power consumers (like HP) get maybe 15-30 minutes warning, and the chance to close things down. There's clearly a protocol within HP as to how to deal with this, as only a few people were running round like lunatics shutting things down. Most people were turning off their workstations and wondering if they should just head off a couple of hours only, particularly those in cubicles some way from natural light.
On a related note, 115F really _is_ too hot.
Well, doesn't that all depend on exactly _who_ you get to do the benchmarking?
30 minutes - she's using NT, right?