Of course it's legal for a firm to market software that runs on only one platform. You can't require a company to make products for all available markets and users. You can't, in fact, require a business to do business with anyone. What you can do is require that a company not treat equivalent buyers in different ways: if you offer a discount for orders of ketchup by the case, then you have to give all the purchasers the discount. But even that is fuzzy, as defining "equivalent buyers" is pretty much up to the company.
No, please don't use Hungarian notation. In particular, please don't use Microsoft's bastardized version of Hungarian. Hungarian was invented for use with untyped and weakly typed languages (think assembler). See The Great Hungarian Prefix Swindle [www.keysound.org] for a well-though-out essay on the topic.
Purify (now a Rational product) worked (On HP-UX, at least) by
rewriting the system libraries with a new allocator, etc. I'm 90% sure that this was before '96. Hmmm, don't remember if it was the shared libraries or just the static ones. But it might be a starting point.
I ran X (3.whatever, but I'd think 4 would be better, if anything) and fvwm2 with no problem on a Pentium 90 and 32Mb. If it's slow, turn off opaque moves and/or resizes. Use rxvt instead of xterm. You're probably not going to be able to use the Gimp, or do 3-D design work, but it works fine as a development box. It's not the fastest box possible, but it was a nice step up from my 16M 486...
However, intricately formatted things (resumes, tightly laid out forms, "word art" drawings, etc.) won't lay out perfectly. Line breaks end up a bit different, graphic placement on presentation slides is sometimes a bit off, and so forth.
Hmmm, just like when you open such a document on pretty much any Windows/Office machine other than the one it was created on. (Usually because of different printer drivers, or different versions of the printer driver.Or perhaps because Word felt like screwing with the document today. It's hard to tell.)
Re:Audiophiles are *worse* than drug addicts
on
Insanely Audiophile
·
· Score: 2
Moreover, when drug addicts throw their money away, they're usually pumping it back into the local economy instead of shipping it off to hardware manufacturers overseas.
Actually, a lot of "high-end" approved gear is made in the US and Canada (Canada funded some serious speaker research several years ago, and a lot of companies grew out of that, making some fine speakers for a reasonable price).
The police record part is not FUD. You missed this part:
His father repeated to me twice, as if he
couldn't quite believe the whole thing had
actually happened, that the police gave him
a case number and are keeping the report on file.
Now, that may not count as an official "police
record" (and it's certainly not a "criminal record"), but it is more than just questioning.
I suppose this is going to sound anti-marketing, but my main problem (as a programmer working with marketing) wasn't an inability to provide scheduling, it was that my schedules were
ignored
screwed over by constantly changing requirements
screwed over by constantly changing resource availability
After a while, it becomes rather pointless and
tiresome you know are going to be useless next month.
Anyway, to provide some (perhaps) useful information: If you are not a programmer, you can't estimate a schedule. What you can do is guide the choices the programmers make when they do scheduling. List desired features with priorities. List desired finish dates (assuming staged rollouts). When the
programmers say they can only do half of it in the
allotted time, either accept it or work with them
to adjust features/time/resources.
Once everybody
agrees with the features and schedules, let them
work. Don't take people away from the project for
"emergencies". Don't add "just this tiny little
feature". When you do both of the previous (and you will, because the real world is that way), be honest about what you're doing, and adjust the schedule.
At this point, you're probably thinking "Well,
those darn programmers always ask for more time
than they really need, so I need to force them to
do more than they say they can." You're right. We
do. That's because we've all been screwed over by
feature creep and resource loss so many times that we know we have to overestimate to survive, because it's never the marketing guy who takes the
blame for late products. Once your geeks learn they can trust you, their estimates will come closer to what they really think. Besides, nobody ever gets yelled at for beating a schedule, right?
One more trick for a stable unstable: after getting updated to the unstable dist, put at
least the following packages on hold, and only upgrade after the update has been in the archive for a few days without problems:
(any kernel packages that you use)
libc6
dpkg
apt
perl (probably)
this should keep you out of the most destructive problems that might occur. You also
ought to be at least scanning debian-devel.
It was (is?) fairly common practice for real, out on the sidewalk street performers to pass the hat before finishing the story/puppet show/whatever, typically at the "cliff-hanger". Thus the name of counterpane's protocol.
And mr duff (yes, probably that mr duff!) pointed out that the Plan 9 under discussion was a ground up research OS built at Bell Labs, and has nothing to do with a DEC product called Forte.
No, the next Y2K scare will the Unix inspired 2038 problem, when all the 32 bit time counters roll over. OpenVMS will still be plugging happily along (even on 32-bit platforms), because the people who designed OpenVMS didn't assume that it would all be replaced in 10 years. (In VMS, the core time representation is a 64 bit quantity, with resolution to a millisecond (IIRC) and range from sometime 1500s until > AD10000.)
Difference between VMS and OpenVMS: 4 letters. Back when Sun/HP/IBM were claiming "open systems", DEC decided to rename the OS. Unfortunately, they did it about the same time they released the first Alpha machines and confused the issue, making some people think that OpenVMS was something to do with the Alphas.
Unix didn't kill VMS. DEC killed VMS through stupid policies. And having used both extensively, and programmed for both extensively, I'll point out that VMS had/has technology that Unix systems (not to mention Linux) are still reaching for. Like clusters: talk to a VMS person sometime, tell him/her about "linux clusters", and then listen to her/him laugh at you. A properly set up VMS cluster is a thing of beauty, with capabilities and reliability orders of magnitude beyond anything available on Unix.
Then tell the VMS person about how we're getting different languages to work together. They will look at you in amazement, wondering why there isn't a standard calling convention that all the languages use.
Yes, DCL (the standard "shell" on VMS) is not the best possible interactive environment -- the unix shells are clearly superior. But DCL isn't VMS, anymore than bash is Unix. The VMS operating system is powerful and complete, and has solved problems the Unix people haven't gotten around to thinking about yet. The only thing that really sucks on VMS is the device:[directory]file.ext;version file names (although once you've lived with *real* (i.e. supported by the OS) file versioning, you miss it a *lot* when you do without).
And we Linux people our proud of our months of uptime, but VMS people measure uptimes and availability in *years*. Many of the production lines and processing plants (refineries, etc.) in the US and around the world are run by OpenVMS machines.
Don't get me wrong: I *like* Unix, and I'd much rather have a Unix box for my day-to-day programming environment (except that the DEC debugger blows away gdb) than VMS, but that's mostly because I'd much rather have bash than DCL. VMS definitely has its annoying quirks and faults. But slamming VMS based on a few weeks use of DCL and not liking the syntax is just prejudice.
See the first question under the "Critique" section at the r3mix site. (I'd put a direct link, but it uses %$^#@! frames.) Short answer: blade and lame started with the same ISO code, but blade hasn't been significantly improved in quite a while, and doesn't support VBR encoding.
Business plan is not broken
on
Tivo Hacking?
·
· Score: 1
People who make business plans should expect that most of their customers will make rational economic decisions.
Let's see, the current price for a 30 hour Tivo is $399. I can get a lifetime (of the unit) contract for $200, or pay $10/month, which includes software upgrades as well as the scheduling service. Total: $600
Or I can buy a PC and write my own software and build my own remote, and build another IR thingie to manipulate the directtv box (possibly). Let's see, a 300Mhz celeron + MB + 128MB memory plus video decoder + mpeg encoder/decoder + 20GB HD + nice case + extra HW for the IR stuff + NIC (to get the schedules) + other stuff I forgot. Is that less than $600? I don't think so. Not to mention time, both to assemble the hardware and to write the software (which is non-trivial -- the Tivo interface does a *lot* of cool stuff.) (Yes, I've seen/messed with one.)
So the rational economic decision is clearly to buy the Tivo. Now, there is certainly the hack value and coolness factor in doing it yourself, and the possibility of implementing features that Tivo doesn't provide, but don't forget that the Tivo is aimed at people who can't set the clock on their VCR, much less program it to record correctly.
Do I wish I could upgrade the harddisks myself? Of course. But the vast majority of the target audience probably doesn't care. And honestly, if you're 30hrs behind in your TV watching, are you likely to ever catch up?
I agree with RG Ristroph's post -- the hard part is establishing version control -- the tool is not the most important part. That said, CVS is a pretty good tool. It works well over both LANs and WANs (unlike sourcesafe, for example), handles branching/merging about as well any as tool can, and bonus, is free. You *will* need someone who is dedicated to managing the system and answering questions. It may not (should not) be a full-time job, but until people are up-to-speed, they will make mistakes, and you need someone whose priority it is to fix those mistakes, and help the other developers learn how to accomplish what they need. (The above is true of any version control system, by the way, not just CVS.)
Before you install any VC system, you need to decide what you're trying to accomplish, and design the procedures to do that. CVS (or whatever) is a tool, not a methodology.
Finally, here are some hopefully useful links:
Karl Fogel's CVS book (actually, portions of it, mostly dealing with using CVS), which I find more readable than the Cederquist manual.
Some links about using CVS for websites:here, here, and here. Different view points, worth reading, and generally applicable even if you choose something besides CVS.
Well, not totally, but there are so many errors and misconceptions in the question I'm not sure how to answer.
Since there are now so many different flavors of UNIX out there (Linux, Free BSD, AIX, Solaris, AT&T UNIX, etc...) what do they all have in common that lets these all be called UNIX? Programs written for one flavor of UNIX typically cannot be ported to another without considerable effort.
Wrong. Well-written programs can be easily ported from one unix to another. The problem is that many programs are written by people who have a relatively poor understanding of how to write portable code, and no idea how to distinguish the C standard, the POSIX standard, stuff that's not POSIX but almost universally available on Unix and Unix-like systems, and stuff that is specific to a particular implementation.
The features offered by the different implementations vary widely: some are more secure than others, some cluster better than others, some offer journaling file systems, some are more robust.
None of which has anything to with writing portable code. For example, the C interface to the file system (fopen(), fprintf()) and posix interface (open(), read(), write()) make the underlying file system transparent. Of course, if you're writing a tool to manage a cluster, it's going to be implementation specific.
The differences between the different kinds of UNIX seem to be as great as the differences between any particular implementation and other OSs.
Sorry, you've obviously never actually had to write programs that worked on a wide variety of systems. I used to work on a large product that ran on a variety of Unix systems, OpenVMS, and NT. IIRC, the only difference between the Unices was different options to mmap() and dealing with an old version of SunOS that didn't implement POSIX signals quite correctly. (Of course, there were many differences to the system headers, but those are supplied by the vendor, and are there precisely so that you don't have to worry about internal differences.) FWIW, the OpenVMS version was pretty easy, because even the the system calls were totally different, most of the concepts mapped pretty well. NT, on the otherhand, was a complete pain in the ass.
Now obviously, one *can* write code that is specific to a particular Unix implementation. And noone will argue that at the admin level, things are aren't chaos.
Could one port all the standard command line utilities to NT, clone one or two of the popular shells, set up the directory structure in the standard UNIX layout and call it Microsoft UNIX?
No, because you haven't changed the syscall interface. Cygwin comes a lot closer, but was also a lot more work than what you've proposed.
I agree with the recommendation, but you need to be aware that the first 15-30 pages (not sure,it's been awhile) are an almost unreadable history of detailed church history leading into the story. Unfortunately, you can't just skip it, because it's crucial to the plot (eventually). Bear with it, struggle through; it's not that way through the whole book.
Slashdot Mirror
>> Is /bin/sh POSIX on all major platforms? Or do
/bin/posix/sh?
/bin/sh should be POSIX compliant, yes
>> some have it in an alternate location like
>>
> In theory,
> - there's certainly grounds for complaint if it's not.
Tell that to Sun. Please.
Of course it's legal for a firm to market software that runs on only one platform. You can't require a company to make products for all available markets and users. You can't, in fact, require a business to do business with anyone. What you can do is require that a company not treat equivalent buyers in different ways: if you offer a discount for orders of ketchup by the case, then you have to give all the purchasers the discount. But even that is fuzzy, as defining "equivalent buyers" is pretty much up to the company.
I can't believe that got modded up
Was there any point in publishing this on the afternoon of the day of the end of the comment period?
How does this rate as "Informative"? The guy
mentioned Octave in his question!
No, please don't use Hungarian notation. In particular, please don't use Microsoft's bastardized version of Hungarian. Hungarian was invented for use with untyped and weakly typed languages (think assembler). See The Great Hungarian Prefix Swindle [www.keysound.org] for a well-though-out essay on the topic.
Purify (now a Rational product) worked (On HP-UX, at least) by rewriting the system libraries with a new allocator, etc. I'm 90% sure that this was before '96. Hmmm, don't remember if it was the shared libraries or just the static ones. But it might be a starting point.
I ran X (3.whatever, but I'd think 4 would be better, if anything) and fvwm2 with no problem on a Pentium 90 and 32Mb. If it's slow, turn off opaque moves and/or resizes. Use rxvt instead of xterm. You're probably not going to be able to use the Gimp, or do 3-D design work, but it works fine as a development box. It's not the fastest box possible, but it was a nice step up from my 16M 486...
However, intricately formatted things (resumes, tightly laid out forms, "word art" drawings, etc.) won't lay out perfectly. Line breaks end up a bit different, graphic placement on presentation slides is sometimes a bit off, and so forth.
Hmmm, just like when you open such a document on pretty much any Windows/Office machine other than the one it was created on. (Usually because of different printer drivers, or different versions of the printer driver.Or perhaps because Word felt like screwing with the document today. It's hard to tell.)
Moreover, when drug addicts throw their money away, they're usually pumping it back into the local economy instead of shipping it off to hardware manufacturers overseas.
Actually, a lot of "high-end" approved gear is made in the US and Canada (Canada funded some serious speaker research several years ago, and a lot of companies grew out of that, making some fine speakers for a reasonable price).
The police record part is not FUD. You missed this part:
His father repeated to me twice, as if he couldn't quite believe the whole thing had actually happened, that the police gave him a case number and are keeping the report on file.
Now, that may not count as an official "police record" (and it's certainly not a "criminal record"), but it is more than just questioning.
After a while, it becomes rather pointless and tiresome to provide schedules you know are going to be useless next month.
Sorry about that...
I suppose this is going to sound anti-marketing, but my main problem (as a programmer working with marketing) wasn't an inability to provide scheduling, it was that my schedules were
After a while, it becomes rather pointless and tiresome you know are going to be useless next month.
Anyway, to provide some (perhaps) useful information: If you are not a programmer, you can't estimate a schedule. What you can do is guide the choices the programmers make when they do scheduling. List desired features with priorities. List desired finish dates (assuming staged rollouts). When the programmers say they can only do half of it in the allotted time, either accept it or work with them to adjust features/time/resources.
Once everybody agrees with the features and schedules, let them work. Don't take people away from the project for "emergencies". Don't add "just this tiny little feature". When you do both of the previous (and you will, because the real world is that way), be honest about what you're doing, and adjust the schedule.
At this point, you're probably thinking "Well, those darn programmers always ask for more time than they really need, so I need to force them to do more than they say they can." You're right. We do. That's because we've all been screwed over by feature creep and resource loss so many times that we know we have to overestimate to survive, because it's never the marketing guy who takes the blame for late products. Once your geeks learn they can trust you, their estimates will come closer to what they really think. Besides, nobody ever gets yelled at for beating a schedule, right?
David Brin wrote Earth, not David Gerrold.
One more trick for a stable unstable: after getting updated to the unstable dist, put at least the following packages on hold, and only upgrade after the update has been in the archive for a few days without problems:
this should keep you out of the most destructive problems that might occur. You also ought to be at least scanning debian-devel.
It was (is?) fairly common practice for real, out on the sidewalk street performers to pass the hat before finishing the story/puppet show/whatever, typically at the "cliff-hanger". Thus the name of counterpane's protocol.
And mr duff (yes, probably that mr duff!) pointed out that the Plan 9 under discussion was a ground up research OS built at Bell Labs, and has nothing to do with a DEC product called Forte.
No, the next Y2K scare will the Unix inspired 2038 problem, when all the 32 bit time counters roll over. OpenVMS will still be plugging happily along (even on 32-bit platforms), because the people who designed OpenVMS didn't assume that it would all be replaced in 10 years. (In VMS, the core time representation is a 64 bit quantity, with resolution to a millisecond (IIRC) and range from sometime 1500s until > AD10000.)
Difference between VMS and OpenVMS: 4 letters. Back when Sun/HP/IBM were claiming "open systems", DEC decided to rename the OS. Unfortunately, they did it about the same time they released the first Alpha machines and confused the issue, making some people think that OpenVMS was something to do with the Alphas.
"Legacy systems: the ones that work."
Unix didn't kill VMS. DEC killed VMS through stupid policies. And having used both extensively, and programmed for both extensively, I'll point out that VMS had/has technology that Unix systems (not to mention Linux) are still reaching for. Like clusters: talk to a VMS person sometime, tell him/her about "linux clusters", and then listen to her/him laugh at you. A properly set up VMS cluster is a thing of beauty, with capabilities and reliability orders of magnitude beyond anything available on Unix.
Then tell the VMS person about how we're getting different languages to work together. They will look at you in amazement, wondering why there isn't a standard calling convention that all the languages use.
Yes, DCL (the standard "shell" on VMS) is not the best possible interactive environment -- the unix shells are clearly superior. But DCL isn't VMS, anymore than bash is Unix. The VMS operating system is powerful and complete, and has solved problems the Unix people haven't gotten around to thinking about yet. The only thing that really sucks on VMS is the device:[directory]file.ext;version file names (although once you've lived with *real* (i.e. supported by the OS) file versioning, you miss it a *lot* when you do without).
And we Linux people our proud of our months of uptime, but VMS people measure uptimes and availability in *years*. Many of the production lines and processing plants (refineries, etc.) in the US and around the world are run by OpenVMS machines.
Don't get me wrong: I *like* Unix, and I'd much rather have a Unix box for my day-to-day programming environment (except that the DEC debugger blows away gdb) than VMS, but that's mostly because I'd much rather have bash than DCL. VMS definitely has its annoying quirks and faults. But slamming VMS based on a few weeks use of DCL and not liking the syntax is just prejudice.
See the first question under the "Critique" section at the r3mix site. (I'd put a direct link, but it uses %$^#@! frames.) Short answer: blade and lame started with the same ISO code, but blade hasn't been significantly improved in quite a while, and doesn't support VBR encoding.
People who make business plans should expect that most of their customers will make rational economic decisions.
Let's see, the current price for a 30 hour Tivo is $399. I can get a lifetime (of the unit) contract for $200, or pay $10/month, which includes software upgrades as well as the scheduling service. Total: $600
Or I can buy a PC and write my own software and build my own remote, and build another IR thingie to manipulate the directtv box (possibly). Let's see, a 300Mhz celeron + MB + 128MB memory plus video decoder + mpeg encoder/decoder + 20GB HD + nice case + extra HW for the IR stuff + NIC (to get the schedules) + other stuff I forgot. Is that less than $600? I don't think so. Not to mention time, both to assemble the hardware and to write the software (which is non-trivial -- the Tivo interface does a *lot* of cool stuff.) (Yes, I've seen/messed with one.)
So the rational economic decision is clearly to buy the Tivo. Now, there is certainly the hack value and coolness factor in doing it yourself, and the possibility of implementing features that Tivo doesn't provide, but don't forget that the Tivo is aimed at people who can't set the clock on their VCR, much less program it to record correctly.
Do I wish I could upgrade the harddisks myself? Of course. But the vast majority of the target audience probably doesn't care. And honestly, if you're 30hrs behind in your TV watching, are you likely to ever catch up?
I agree with RG Ristroph's post -- the hard part is establishing version control -- the tool is not the most important part. That said, CVS is a pretty good tool. It works well over both LANs and WANs (unlike sourcesafe, for example), handles branching/merging about as well any as tool can, and bonus, is free. You *will* need someone who is dedicated to managing the system and answering questions. It may not (should not) be a full-time job, but until people are up-to-speed, they will make mistakes, and you need someone whose priority it is to fix those mistakes, and help the other developers learn how to accomplish what they need. (The above is true of any version control system, by the way, not just CVS.)
Before you install any VC system, you need to decide what you're trying to accomplish, and design the procedures to do that. CVS (or whatever) is a tool, not a methodology.
Finally, here are some hopefully useful links:
Came accross this in Freshmeat (while looking for something else), it claims to support PERT and Gantt charts. It's on Sourceforge here
Well, not the best possible interface, but try this:
://www.pbs.org/whatson/stations/fulltext.html?stat ion=KUHT&date=2000-04-01, except substitute your stations call letters and a date from the month you wish to examine. It will bring up the entire month's programming, and you can then use your browsers text search function.
http
(Let's see, Houston, 4th largest city in the US, lots of high-tech business: Code Rush, 5am, 4/21.
Beautiful.)
Well, not totally, but there are so many errors and misconceptions in the question I'm not sure how to answer.
Since there are now so many different flavors of UNIX out there (Linux, Free BSD, AIX, Solaris, AT&T UNIX, etc...) what do they all have in common that lets these all be called UNIX? Programs written for one flavor of UNIX typically cannot be ported to another without considerable effort.
Wrong. Well-written programs can be easily ported from one unix to another. The problem is that many programs are written by people who have a relatively poor understanding of how to write portable code, and no idea how to distinguish the C standard, the POSIX standard, stuff that's not POSIX but almost universally available on Unix and Unix-like systems, and stuff that is specific to a particular implementation.
The features offered by the different implementations vary widely: some are more secure than others, some cluster better than others, some offer journaling file systems, some are more robust.
None of which has anything to with writing portable code. For example, the C interface to the file system (fopen(), fprintf()) and posix interface (open(), read(), write()) make the underlying file system transparent. Of course, if you're writing a tool to manage a cluster, it's going to be implementation specific.
The differences between the different kinds of UNIX seem to be as great as the differences between any particular implementation and other OSs.
Sorry, you've obviously never actually had to write programs that worked on a wide variety of systems. I used to work on a large product that ran on a variety of Unix systems, OpenVMS, and NT. IIRC, the only difference between the Unices was different options to mmap() and dealing with an old version of SunOS that didn't implement POSIX signals quite correctly. (Of course, there were many differences to the system headers, but those are supplied by the vendor, and are there precisely so that you don't have to worry about internal differences.) FWIW, the OpenVMS version was pretty easy, because even the the system calls were totally different, most of the concepts mapped pretty well. NT, on the otherhand, was a complete pain in the ass.
Now obviously, one *can* write code that is specific to a particular Unix implementation. And noone will argue that at the admin level, things are aren't chaos.
Could one port all the standard command line utilities to NT, clone one or two of the popular shells, set up the directory structure in the standard UNIX layout and call it Microsoft UNIX?
No, because you haven't changed the syscall interface. Cygwin comes a lot closer, but was also a lot more work than what you've proposed.
I agree with the recommendation, but you need to be aware that the first 15-30 pages (not sure,it's been awhile) are an almost unreadable history of detailed church history leading into the story. Unfortunately, you can't just skip it, because it's crucial to the plot (eventually). Bear with it, struggle through; it's not that way through the whole book.