From the founders of Excite: http://www.jotspot.com/ Jotspot sells hosting w/ SSL ($9-$250/month) or remotely maintained appliances ($10K-$15K/year); no software.
BusinessWeek's choice: http://www.socialtext.com/ Socialtext sells software and hardware but no hosting (Can't remember the price range right now).
> "If you stop using C/C++ by default and use safer languages such as Java or C#, your code will become more secure. The fact that it still isn't 100% secure doesn't mean you've made no progress. And with fewer vulnerabilities, you can pay more attention to the types of vulnerabilities that remain."
actually, if you stop referring to c++ as "c/c++" and understand that c++ is a separate language and treat it that way, may be you won't need to use java or c# to start with
the problem with c++ is this: even the 'experienced' c++ programmers out there still think of it as a 'better' c and they use it that way. they insist on using pointers everywhere; they insist on avoiding stl; they insist on not learning what a smart pointer is, etc. java or c#, on the other hand, force the programmer to a single paradigm and thus solve the problem that way
it has also something to do with libraries you might wanna use during development. with java and c#, you have sun and microsoft to dictate such libraries. with c++, you are clueless, though. there are excellent libraries out there such as boost and ace but people don't know about them that much. thus, they keep reinventing the wheel, and in a much less secure way, i might add
so, it's not c++ itself but the circumstances surrounding it. people who just can't let go off their c habits and lack of standardized apis make the life of an average c++ programmer much harder. yet, if you educate yourself, then the work you need to do in c++ to achieve security is going to be roughly the same as java or c#
other replies did cover some issues. another issue has to do with the uncertainty of the earth
while drilling, you simply don't know what to expect even when you did previous remote sensing studies ( seismic ). for example, you might hit an unexpected formation and need to change your drill bit. in certain cases, if you can't react fast enough, you might lose the well, which might mean saying bye bye to millions of dollars. so, you wanna be prepared for all kinds of possibilities and for that, you need a ship or a platform
furthermore, there are devices out there which can analyze the mud used while drilling and infer extra information about the formation. for a mechanism like that to work, once again, you need a ship or a platform
actually, this particular problem is apparently due to the use sscanf function, which is c rather than c++. c++ can not save you if you insist on using facilities retained to ensure c compatibility
in the future, may be you should read the reason of the defect before claiming things like this...
-- ba
Re:Excellent review of the book
on
Out of Gas
·
· Score: 1
> "Your point may well be true. Perhaps we can leverage technology to meet demand. But is this a wise bet? If you're wrong, the consequences are potentially catastrophic. If you're right, but we've invested in alternative energy, have we really lost anything besides depriving the oil barons of a few billion? It's mere pocket change, really."
all i am saying is, the *reason* to look for hydrocarbon alternatives should not be because we are gonna run out of hydrocarbons soon because that's simply not true. if we are going to accelerate the research for hydrocarbon alternatives ( and we should ), let's do it for the right reasons. let me put it in a different way: if we knew for sure that we would never run out of oil, would that mean we could relax and not worry about the alternatives?
you might, of course, say "hey, but, shouldn't we spend the money on the alternatives research instead of the pet. eng. research?". the answer to that question is "we should slowly shift the balance from pure pet. eng. to pure alternatives research". you have to understand that, changing the infrastructure of the entire world, which is pretty much depended on oil, is not a very easy thing. thus, the ideal approach to the problem is to continue working on pet. eng. research while slowly decreasing the research activities over the next 15 - 20 years
and, believe me, that is happening already: http://gcep.stanford.edu/
-- ba
Re:Excellent review of the book
on
Out of Gas
·
· Score: 1
from the article:
"There is only so much crude oil in the world, and the industry has found about 90 percent of it."
as petroleum engineering ph.d. from stanford university, i call this bullshit. the authors undermine the power of technology. for example, they dismiss deep water reservoirs by saying "much of the deepwater realm, for example, has been shown to be absolutely non-prospective for geologic reasons" and they dismiss non-conventional oil reserves by saying "but the industry will be hard-pressed for the time and money needed to ramp up production of unconventional oil quickly enough"
the above assessments are simply not true. deep water reservoirs are becoming more and more important for oil companies as we develop new technologies and understand them better. in 1998, they were deemed too hard and too expensive to work on but nowadays they are pretty standard as far as the big oil companies are concerned. non-conventional oil reserves are a similar story. once, they were thought to be hardly producible but now we know that we can produce them rather easily; thanks to again newly emerging techniques
sure, we don't have infinite oil reserves. but, the situation is not as bad as some people claim it to be. yet, that doesn't mean we should feel comfortable. the incentive to find hydrocarbon alternatives should *not* be the distorted 'fact' that we are going to run out of oil soon. it should be the fact that oil consumption is not good for the environment
> "You don't want to write a spec file; I could equally argue that I don't have time to write a setup.exe program."
you don't have to. but, i do
> "Perhaps it would be better to have a pretty GUI to make the spec file rather than writing it in an editor."
no, not "perhaps". definitely. that's the whole point to start with
> "I find it hard to believe that the effort involved to learn how to write an rpm spec file (quite simple) is less than that in learning how to use a new GUI package builder such as Installshield. Especially when you factor in the extra effort to install the package automatically on Windows machines and keep it updated. (And yes, I have done these three things.)"
i also did write spec files. simple ones; ya'know, the ones that show up in how-tos, etc. yet, doing anything slightly complex with a spec file is not easily apparent ( for example, putting links on the desktop ). and, as i said, i really really don't want to rtfm
furthermore, several distributions make life harder. rpm is a generic tool so a single manual rarely covers peculiarities of all distributions. that means, yes, you guessed it, reading more manuals!
with a decent gui, it's different. you get context sensitive help. you might still need to read stuff but it is much easier ( and more pleasant ) reading. plus, with windows, gui-based installers let you tweak things between different windows versions. ya'know, the same thing ( directories, registry settings, etc. ) sometimes appears under different locations on different windows versions. all handled automatically
> "Requiring root is a good point: in my opinion it is not nearly easy enough to install an RPM in your home directory rather than centrally."
apparently so. and, i can't emphasize the importance of this. there is no way for me to get that imaginary engineer call some it admin to make him install my software. instead, he will simply browse through the html help files and then forget about it
seems harsh? no. i worked for some big companies where people were not allowed to install anything on their machines. once, for a project, i needed a c++ compiler, anything other than msvc6, and i let the company know about this requirement 3 months ahead of time. when i arrived, it still took them a month to install the compiler. that's 30 days! why? because someone from the it group had to show up and install it. funny enough, he couldn't install the thing properly so i ended up installing msvc7.1 myself and his sole purpose was decreased to be there to type his admin password
sure, in such a company, my imaginary engineer wouldn't be allowed to install my software anyways. but, then there are some other companies where he can do that yet the it groups of such companies are no different. if i required him to be root, he would still need to get hold of an it admin
note: actually, the kind of software i desire do exist to a degree. funny enough, from the good old windows company installshield. it's called installshield multiplatform. it's not as good as their windows installer ( i don't know about version 5, though ) but still... yet, of course, it's ridiculously expensive ( around $2500, i believe )
> "It does have a single installation method: RPM."
sure because i *love* writing spec files
you are missing the point. i didn't say, it is impossible to create installation packages. i said it is not as easy as on windows. i am not writing a spec file; period. i already have too many things on my plate. i don't intend to learn yet another text file format
which goes back to the subject of this thread: "L00ser syndrome & RTFM". because there is no easy, standard way of building binary rpm packages with a pretty gui ( yes, needs to be pretty ), i become a loser because i have no intention of reading tfm. got my point?
> "I am thinking more about managing installation on a network of 100 or 1000 machines, rather than grandma wanting to install a single app on her own PC."
which is not the case at all
i have to deliver my software to an engineer who does not understand from linux ( but, obviously is a smart fellow ). this guy probably has many responsibilities and "checking out this interesting software" is the least of his worries. on many occasions, i can't go to the site, either. so, i should be able to tell this guy:
- insert the cd you got via mail in your cdrom - using your file browser, go to/mnt/cdrom and run install - follow the instructions shown on the install wizard dialog - done? good; there is a freshly generated symlink on your desktop; click on it and from the file menu, open "sample.prj" to give it a try
the day you give me all of the above without requiring him to be root or needing to use the command line, i'll be good. with that said, to generate the above procedure, i should not be required to use the command line either ( but, being root is ok )
oh, and, if such a software exists, i'd really prefer its version to be > 1.0 as those big companies tend to get pissed big time if some pre-1.0 software screws their system up
> "% apt-get install my-weird-package" > "Make an RPM of your program, upload it to an apt repository (or create a local repository), and then people can easily install it with synaptic or other GUI tools, including all dependencies. Yes, you may need two slightly different RPMs for two distributions, but this is not a big deal."
you would think. there are companies out there who wouldn't let apt to be installed on their local machines. the installer *has* to be a standalone program unless the os itself has a single installation methodology ( such as the msi of windows ). after the install, i should be able to delete all the installation files and everything should be ok
furthermore, some companies use home-brewed linux versions. i don't intend to compile apt for every single distribution out there. the whole idea of having an installation program is to *avoid* compiling code to start with. if i have to compile stuff to install my installer... well, that is just ridiculous
i know this is not apt's fault. linux requires you to do some compiling this way or another because there is no standardization. and, that's pretty much the real issue here
> "The Windows setup.exe model is somewhat broken, trying to imitate it on Linux is the wrong way to go."
why is it broken again? i never had a single problem with it. it works. it works without any problems. it is easy for me to develop and for the users to install. that's pretty much what i expect from an installation system
> "Will Linux ever get past the 'figure it out yourself you l00ser syndrome'."
Yup and what's worse is, it's typically not even the fault of the developer who writes end-user software.
I am one such developer, developing cross-platform apps. Linux is very important to us as we are doing scientific coding. On Windows, I can simply use Inno Setup or something similar and create an easy to use installation package. On Linux, I am yet to find a free alternative as intuitive as Inno Setup or alike. So, in that sense, I am a loser too because I am totally incapable of using the available installation creation tools.
But, here's a question: I hold a Ph.D. from a top USA university and two masters, one on artificial intelligence. I consider myself a good C++ programmer ( I can figure out what Andrei is talking about the first time I read any of his articles or his book ). I taught Java to freshman at a respected college. Have a quite good command of Perl, too. More than 10+ years of coding experience and that's not only scientific coding. I worked on multimedia apps, databases apps, internet apps, etc. Given all this, if I can't figure how a Linux installation system works within 30 minutes, is that really my fault?
I'll change the boot order of my machine when I can code on Linux as easy as I can code on Windows. Unfortunately, I don't see that happening anytime soon; may be, in 3+ years.
Slashdot Mirror
Ooops. I meant Socialtext sells hosting and hardware but no software (They use Kwiki, which is open source).
My favorite: http://www.atlassian.com/software/confluence/
Confluence is just software ($4K + $2k/year); no hardware or hosting.
From the founders of Excite: http://www.jotspot.com/
Jotspot sells hosting w/ SSL ($9-$250/month) or remotely maintained appliances ($10K-$15K/year); no software.
BusinessWeek's choice: http://www.socialtext.com/
Socialtext sells software and hardware but no hosting (Can't remember the price range right now).
You might also want to look into search appliances such as Google's enterprise stuff:
http://www.google.com/enterprise/
> "If you stop using C/C++ by default and use safer languages such as Java or C#, your code will become more secure. The fact that it still isn't 100% secure doesn't mean you've made no progress. And with fewer vulnerabilities, you can pay more attention to the types of vulnerabilities that remain."
actually, if you stop referring to c++ as "c/c++" and understand that c++ is a separate language and treat it that way, may be you won't need to use java or c# to start with
the problem with c++ is this: even the 'experienced' c++ programmers out there still think of it as a 'better' c and they use it that way. they insist on using pointers everywhere; they insist on avoiding stl; they insist on not learning what a smart pointer is, etc. java or c#, on the other hand, force the programmer to a single paradigm and thus solve the problem that way
it has also something to do with libraries you might wanna use during development. with java and c#, you have sun and microsoft to dictate such libraries. with c++, you are clueless, though. there are excellent libraries out there such as boost and ace but people don't know about them that much. thus, they keep reinventing the wheel, and in a much less secure way, i might add
so, it's not c++ itself but the circumstances surrounding it. people who just can't let go off their c habits and lack of standardized apis make the life of an average c++ programmer much harder. yet, if you educate yourself, then the work you need to do in c++ to achieve security is going to be roughly the same as java or c#
-- ba
other replies did cover some issues. another issue has to do with the uncertainty of the earth
while drilling, you simply don't know what to expect even when you did previous remote sensing studies ( seismic ). for example, you might hit an unexpected formation and need to change your drill bit. in certain cases, if you can't react fast enough, you might lose the well, which might mean saying bye bye to millions of dollars. so, you wanna be prepared for all kinds of possibilities and for that, you need a ship or a platform
furthermore, there are devices out there which can analyze the mud used while drilling and infer extra information about the formation. for a mechanism like that to work, once again, you need a ship or a platform
-- ba
actually, this particular problem is apparently due to the use sscanf function, which is c rather than c++. c++ can not save you if you insist on using facilities retained to ensure c compatibility
in the future, may be you should read the reason of the defect before claiming things like this...
-- ba
> "Your point may well be true. Perhaps we can leverage technology to meet demand. But is this a wise bet? If you're wrong, the consequences are potentially catastrophic. If you're right, but we've invested in alternative energy, have we really lost anything besides depriving the oil barons of a few billion? It's mere pocket change, really."
all i am saying is, the *reason* to look for hydrocarbon alternatives should not be because we are gonna run out of hydrocarbons soon because that's simply not true. if we are going to accelerate the research for hydrocarbon alternatives ( and we should ), let's do it for the right reasons. let me put it in a different way: if we knew for sure that we would never run out of oil, would that mean we could relax and not worry about the alternatives?
you might, of course, say "hey, but, shouldn't we spend the money on the alternatives research instead of the pet. eng. research?". the answer to that question is "we should slowly shift the balance from pure pet. eng. to pure alternatives research". you have to understand that, changing the infrastructure of the entire world, which is pretty much depended on oil, is not a very easy thing. thus, the ideal approach to the problem is to continue working on pet. eng. research while slowly decreasing the research activities over the next 15 - 20 years
and, believe me, that is happening already: http://gcep.stanford.edu/
-- ba
from the article:
"There is only so much crude oil in the world, and the industry has found about 90 percent of it."
as petroleum engineering ph.d. from stanford university, i call this bullshit. the authors undermine the power of technology. for example, they dismiss deep water reservoirs by saying "much of the deepwater realm, for example, has been shown to be absolutely non-prospective for geologic reasons" and they dismiss non-conventional oil reserves by saying "but the industry will be hard-pressed for the time and money needed to ramp up production of unconventional oil quickly enough"
the above assessments are simply not true. deep water reservoirs are becoming more and more important for oil companies as we develop new technologies and understand them better. in 1998, they were deemed too hard and too expensive to work on but nowadays they are pretty standard as far as the big oil companies are concerned. non-conventional oil reserves are a similar story. once, they were thought to be hardly producible but now we know that we can produce them rather easily; thanks to again newly emerging techniques
sure, we don't have infinite oil reserves. but, the situation is not as bad as some people claim it to be. yet, that doesn't mean we should feel comfortable. the incentive to find hydrocarbon alternatives should *not* be the distorted 'fact' that we are going to run out of oil soon. it should be the fact that oil consumption is not good for the environment
-- ba
> "You don't want to write a spec file; I could equally argue that I don't have time to write a setup.exe program."
you don't have to. but, i do
> "Perhaps it would be better to have a pretty GUI to make the spec file rather than writing it in an editor."
no, not "perhaps". definitely. that's the whole point to start with
> "I find it hard to believe that the effort involved to learn how to write an rpm spec file (quite simple) is less than that in learning how to use a new GUI package builder such as Installshield. Especially when you factor in the extra effort to install the package automatically on Windows machines and keep it updated. (And yes, I have done these three things.)"
i also did write spec files. simple ones; ya'know, the ones that show up in how-tos, etc. yet, doing anything slightly complex with a spec file is not easily apparent ( for example, putting links on the desktop ). and, as i said, i really really don't want to rtfm
furthermore, several distributions make life harder. rpm is a generic tool so a single manual rarely covers peculiarities of all distributions. that means, yes, you guessed it, reading more manuals!
with a decent gui, it's different. you get context sensitive help. you might still need to read stuff but it is much easier ( and more pleasant ) reading. plus, with windows, gui-based installers let you tweak things between different windows versions. ya'know, the same thing ( directories, registry settings, etc. ) sometimes appears under different locations on different windows versions. all handled automatically
> "Requiring root is a good point: in my opinion it is not nearly easy enough to install an RPM in your home directory rather than centrally."
apparently so. and, i can't emphasize the importance of this. there is no way for me to get that imaginary engineer call some it admin to make him install my software. instead, he will simply browse through the html help files and then forget about it
seems harsh? no. i worked for some big companies where people were not allowed to install anything on their machines. once, for a project, i needed a c++ compiler, anything other than msvc6, and i let the company know about this requirement 3 months ahead of time. when i arrived, it still took them a month to install the compiler. that's 30 days! why? because someone from the it group had to show up and install it. funny enough, he couldn't install the thing properly so i ended up installing msvc7.1 myself and his sole purpose was decreased to be there to type his admin password
sure, in such a company, my imaginary engineer wouldn't be allowed to install my software anyways. but, then there are some other companies where he can do that yet the it groups of such companies are no different. if i required him to be root, he would still need to get hold of an it admin
note: actually, the kind of software i desire do exist to a degree. funny enough, from the good old windows company installshield. it's called installshield multiplatform. it's not as good as their windows installer ( i don't know about version 5, though ) but still... yet, of course, it's ridiculously expensive ( around $2500, i believe )
-- ba
> "It does have a single installation method: RPM."
/mnt/cdrom and run install
sure because i *love* writing spec files
you are missing the point. i didn't say, it is impossible to create installation packages. i said it is not as easy as on windows. i am not writing a spec file; period. i already have too many things on my plate. i don't intend to learn yet another text file format
which goes back to the subject of this thread: "L00ser syndrome & RTFM". because there is no easy, standard way of building binary rpm packages with a pretty gui ( yes, needs to be pretty ), i become a loser because i have no intention of reading tfm. got my point?
> "I am thinking more about managing installation on a network of 100 or 1000 machines, rather than grandma wanting to install a single app on her own PC."
which is not the case at all
i have to deliver my software to an engineer who does not understand from linux ( but, obviously is a smart fellow ). this guy probably has many responsibilities and "checking out this interesting software" is the least of his worries. on many occasions, i can't go to the site, either. so, i should be able to tell this guy:
- insert the cd you got via mail in your cdrom
- using your file browser, go to
- follow the instructions shown on the install wizard dialog
- done? good; there is a freshly generated symlink on your desktop; click on it and from the file menu, open "sample.prj" to give it a try
the day you give me all of the above without requiring him to be root or needing to use the command line, i'll be good. with that said, to generate the above procedure, i should not be required to use the command line either ( but, being root is ok )
oh, and, if such a software exists, i'd really prefer its version to be > 1.0 as those big companies tend to get pissed big time if some pre-1.0 software screws their system up
-- ba
> "% apt-get install my-weird-package"
> "Make an RPM of your program, upload it to an apt repository (or create a local repository), and then people can easily install it with synaptic or other GUI tools, including all dependencies. Yes, you may need two slightly different RPMs for two distributions, but this is not a big deal."
you would think. there are companies out there who wouldn't let apt to be installed on their local machines. the installer *has* to be a standalone program unless the os itself has a single installation methodology ( such as the msi of windows ). after the install, i should be able to delete all the installation files and everything should be ok
furthermore, some companies use home-brewed linux versions. i don't intend to compile apt for every single distribution out there. the whole idea of having an installation program is to *avoid* compiling code to start with. if i have to compile stuff to install my installer... well, that is just ridiculous
i know this is not apt's fault. linux requires you to do some compiling this way or another because there is no standardization. and, that's pretty much the real issue here
> "The Windows setup.exe model is somewhat broken, trying to imitate it on Linux is the wrong way to go."
why is it broken again? i never had a single problem with it. it works. it works without any problems. it is easy for me to develop and for the users to install. that's pretty much what i expect from an installation system
-- ba
> "Will Linux ever get past the 'figure it out yourself you l00ser syndrome'."
Yup and what's worse is, it's typically not even the fault of the developer who writes end-user software.
I am one such developer, developing cross-platform apps. Linux is very important to us as we are doing scientific coding. On Windows, I can simply use Inno Setup or something similar and create an easy to use installation package. On Linux, I am yet to find a free alternative as intuitive as Inno Setup or alike. So, in that sense, I am a loser too because I am totally incapable of using the available installation creation tools.
But, here's a question: I hold a Ph.D. from a top USA university and two masters, one on artificial intelligence. I consider myself a good C++ programmer ( I can figure out what Andrei is talking about the first time I read any of his articles or his book ). I taught Java to freshman at a respected college. Have a quite good command of Perl, too. More than 10+ years of coding experience and that's not only scientific coding. I worked on multimedia apps, databases apps, internet apps, etc. Given all this, if I can't figure how a Linux installation system works within 30 minutes, is that really my fault?
I'll change the boot order of my machine when I can code on Linux as easy as I can code on Windows. Unfortunately, I don't see that happening anytime soon; may be, in 3+ years.
-- ba