I still don't think most of the work is 'art' and I don't believe that what 95% of people do couldn't be done by a replacement just as easily.
I'm sure there are a few jobs that the public wouln't recognize that are a black art, that you can't train someone in, they have to apprentice and pick it up by osmosis, and I'll even grant that some of these jobs might be important to the final quality the film.
But, I'm sure these are few and far between. For every focus puller there are ten assistants to the stars, who are being listed more and more often, and caterers, etc.
Why am I sure? What's my vast experience in the theatre industry? Zip. I admit that. But I've worked a lot of jobs and seen that it's very rare more then 10% of the people in a company actually work on the final product, everyone else just supports the people who do. I don't imagine hollywood, which is about money, not art, at least at any big studio, is any different. (At least, this is how the money end sees it, I'm sure the workers usually see it as more than just another movie.)
I've even had a gopher job. I did incredibly dull stuff and waited on my boss. I took phone calls, did minor paperwork, got coffee, etc, all so she could keep working. And I'm sure she got more work done because of it... But, I don't think that I influenced the quality or design of her work, just the ammount of it. And I could have been replaced by any equally trained gopher who would have been just as helpful to her. If someone had asked about her work, should I have volunteered that I helped make it? Should it have been in my contract with her that I must get mentioned?
And I'm not making the assumption that because I don't understand it, it must be easy. Some of what I did took months before I could do a single task as well as she could. And I also wrote custom tracking software, and did many other non-trivial things. But, I still didn't produce the final product. She did. If I was sick, work went on. When I eventually left, work went on.
And it's not like this is an amateur play where the support staff does it out of the good of their hearts. This is payed work. The same thing almost everyone else does every day.
To me, credits are a way of finding out who did something in the movie that you saw and liked. Actors names are listed so you can identify them. The director is listed, as are many of the important FX people so you can identify their work. But, if a job doesn't affect the quality of the movie directly, it is unimportant to the audience.
It doesn't really matter. The contracts are already written, and the film cost is negligible compared to the length of the movie. I'm not campaigning to wipe out credits, just to explain why I, and obviously a lot of other people, feel the way I do about them.
Re:No to encryption on new storage media
on
A 140GB CD-ROM?
·
· Score: 2
I didn't mention legal issues because I was talking about codecs.
As in, you don't really need to hammer out all of the possible video formats, as long as there's a way to describe the format to the player (a codec) supplied on the disc or accessible on the net, etc.
This is like a player which understands MPEG files getting a disc with an AVI (for example) on it. The disc could include the codec, or a URL to download it. The player could either cache this codec in NVRAM, or simply load it everytime it was needed.
As for the legality... pretty much everything involving copyrights is now illegal, or will be as of the new year, in the USA. The Digital Millenium act really screwed you guys over.
But, even so, if it was designed properly and players had a large secret key that they could use for authentication, yes, you could run a system where the player not only downloaded the actual decryption system, but also an encrypted (for its secret key only) key which would allow viewing of the disc.
But, I think that any form of authentication being needed to view a copyrighted work for which you paid to be able to view, is evil. It's like DIVX... you have the right to view the content only as long as the company says you can, in the way they want, and while they are in business.
But they're annoyingly PC. Gone are the days of credits being for people who actually did something. Now you've got to include everyone in the department, if not their families.
The grips of the world, and their office counterparts, who do jobs that need to be done, but who don't have any effect on the final product simply don't need to be listed.
If the movie or software credits were carried into other fields, you'd see companies crediting their janitorial staff alongside their engineers for new consumer electronics.
Maybe it's a great way to pacify the workers, but that doesn't mean it makes sense.
Actually, including that many credits in the movie WOULD increase ticket price, seeing as the credits do take up film, and studios always bitch about how expensive film is. But, that's pretty well offtopic.
Including people who aren't involved in acting, directing, or creating sets/effects, distracts from the listing of the people who actually affected the movie/couldn't be replaced with temp workers.
It may be cool for you to have your name listed, but do you honestly expect people to believe that you affected the final movie in any way? If those cords hadn't been taped a certain way, that scene just wouldn't have worked?
So, you include 40,000 names. Wow. That's going to be exciting to read. Nobody, not even the obsessive types who've posted in this thread, would stay to read that, it'd be like reading a phonebook.
And are the names meaningful? Are they simply an alphabetic listing of everyone who worked at the company during the product development, or do you list people in order of importance?
Listing actors above grips is appropriate in a movie because actors (unfortunately) are a commodity. People pay to see films starring a certain actor even if they wouldn't have watched the film otherwise. The same isn't true about the grip, the makeup staff, etc.
But, with software (with the exception of some people buying anything John Carmack writes for instace...) you buy the product because of what it is (or what it does) not because of who wrote it.
In this case, the lead programmer (who probably spent most of his time in meetings) is less important that the grunts who slaved away writing the actual thing. So how do you justify listing the lead programmer above the grunts? There are no accurate ways to determine who to list. (Look at the argument surrounding how to judge a programmer's output.) So you either piss off half the staff by listing some ass-kissing management guy first, or ruin the list by simply making it an alphabetic list of names.
The alphabetic list of names might work for small projects, less than a hundred or so people, when the people listed could easily point their name out to friends. But what about a product like MS Office, or Mac OS X... I wouldn't doubt that five or ten thousand people helped in some way to make those products.
So, lacking a fair and interesting way to list the credits, I agree with the decision to scrap them.
Or, as I said earlier, replace them with a 'team credit', where the particular dev team gets to make their own logo and display that...
Re:No to encryption on new storage media
on
A 140GB CD-ROM?
·
· Score: 2
Probably irrelevant. General purpose computers are getting so cheap that by the time a format capable of replacing DVD (offering actual improvements) came around, the players would probably be integrated with a computer. (Even if the user didn't have a monitor and didn't ever explore that aspect of the device.)
So, as long as there was a filesystem on there, the format of the files is fairly unimportant as long as it's not proprietary.
Then if the disk needed a specific codec, it could simply ship with it, or the computer could grab it off the net.
And a general purpose computer would be able to understand that a raw image at 128khz, 64b is the same basic thing as 44khz, 16b, and use the same codec with different parameters, thus pleasing audiophiles who demand every last irrelevant bit be the same, and pleasing techies to whom a VBR MP3 is more appropriate.
On a slightly offtopic rant...
It pisses me off when people demand uncompressed audio of incredibly high data rates. Sure, some piece of music might benefit from having that fidelity at one point, but at all others, it's wasted. The appropriate design would use whatever bandwidth was available and use lossy compression. If that signal needs to be reproduced, then do so, but don't waste the bandwidth by representing all data equally when some is obviously more important.
For any digital lossless compression, a smart encoder could produce a better representation of the original by encoding a higher quality initial signal in the same space.
For an install disk. Well, not for a few years. Five maybe.
Graphics are HUGE. Movies are even bigger.
When everyone is playing games in 2048x1536x32b, and games have to either have tons of textures, or in the case of top-down games, tons of distinct landscapes, we'll be looking at 140GB and complaining that it's not enough.
A flight-sim could use this already. As could a decent off-road driving game.
And as it becomes available, people will use it, precalculating huge data structures to save themselves the trouble of doing it on the fly. (It's not always a bad thing... Quake's BSP trees are precalculated.)
140 hours of video could allow for a kick-ass interactive movie. Imagine if there was actually room to store alternate paths for a bunch of different decisions.
I've had the idea of, when space allows, including a map of all roads in North America (all roads mapped in electronic format at any rate) and not only pictures of actual building near the road, but a rough map of the land nearby. Imagine a driving game like Cannonball Run, where you aren't looping around some dull track, but the game starts in one city and ends in another, and all paved roads in both are in the game. Combine that with textures 3d models of the main buildings and landscaping that you can see from the road. Then further imagine you had the ability to go cross country, cutting across fields as a shortcut.
If storage wasn't a problem, the modelling/texture mapping could be handled with a GPS, a decent laser range finder, a high res digital camera, and some software. Toss it into a van and drive slowly around the area. The GPS knows where you are, space around you would be mapped with the laser, and buildings photographed for the textures. Simply things like light posts could even be identified and replaced with stock models.
It's beyond or capabilities now, but I bet in five years, EA Sports will be seriously considering it.
You're talking about that thing that was later included in the MS screensavers, right?
The 2d maze with 90 degree walls and low-res textures?
That's a long way from a doom client.
Any decent demo coder could whip something like that up in under 4k, 8k if it required textures.
Alright, so MS probably did it in VB and took a few megs, but it's not like they actually stuck Doom in there.
As an example... I saw a 4k demo with music (only on a GUS I believe) which was basically a flyby of the first level of Descent 1, without robots or the reactor, and some level simplification. But it didn't use 90 degree walls, wasn't 2d, wasn't slow...
It was a really cool example of demo coding, and was one of the best examples that demos aren't irrelevent. They basically duplicated the rendering loop of Descent in 4k of assembly. (portal rendering systems are fairly easy to do.)
If anyone has this demo, maybe they can uuencode it and post it, it's small enough to not cause a problem.
Do you read them all, caring about the name of the grip, or do you do it looking for the odd joke, and waiting till the theatre empties?
Movies have the same problem software is starting to have. Way too many people to list. You either list just the big names, thus pissing off people who didn't make the cut, or you list everyone, drowning out the names of the important people, or you go with the minimum, ie those people whose union contracts require them to be listed.
In my opinion, listing grips and other people in movie credits is ridiculous. Their influence is insignificant, and doesn't take any 'art', they could be easily replace by anyone else trained in the field and the work wouldn't suffer.
If you start listing everyone in software projects, either you get insanely long lists, which have to be alphabetically sorted (to avoid fights over priority) and include everyone from the lead programmers down to temporary data entry staff, or you get arbitrarily short lists and piss people off.
A company like id software can do it, because they have few enough employees, and all of them (even, so they say, their secretary/mom) have enough influence on the project that listing them isn't a joke. But this is because they have less than twenty people involved in actually making the game.
And even then it's a stretch. They aren't mentioning any of the testers, famous ones like Thresh, or anonymous ones at Activision, or (I think) the guy who now maintains the eiting tools, etc.
So, being that any attempt to list credits in a company with more than 20-30 people is going to be flawed, I think it's something that should best be left out.
What they could do, if they make feel team spirit, is to code some cool effect, and use the team's internal codename (if they have one.) Thus getting an easter egg, and team pride, without the task of having to name each and every person at all responsible in such a way that wouldn't piss anyone off.
The 'lamp' could really be anything electrical that wouldn't be placed in a closet.
If a PC was tampered with to make it listen for a network connection on the IR port, then you could do anything on the larger network that the PC could. And the 'lamp' could rebroadcast the weak signal with enough power to reach a station across the street, or in some other unsecured area, where the attacker could setup a more robust phone or cellular connection to the actual hacking base station.
And, a lamp would be a good thing to stick an IR rebroadcaster in for a number of reasons. Lamps are fairly electrically noisy, a sweep of the room with an inductive amplifier wouldn't pick up the rebroadcaster because of the 'noise' of the lamp. Lamps are also a fairly common, and come in endless styles. A lamp suitable for an IR rebroadcaster (one with IR transparent plastic on the base) could be easily found and wouldn't look too out of place.
As someone else said, this attack doesn't need to be made on the server, or in the server room. All you need is some non-techy who has access via the network to the information you want. Or, has access to something that will through hacking, allow you to gain further access.
Lamps are great because they're the least technical, and thus the most likely to function properly, electronic device present on most desks.
I think the idea is a little far fetched, but that's probably because most of the security I deal with is for my company and at most, our data is orders of magnitude less important (financially) than fund transfers, making an attempt with a high initial cost and moderate risk (physical intrusion), very unlikely.
Spoofing only refers to packets in our context, that of network types.
But, a spoof (a hoax) is a trick of any type to substitute something fake for something real. You could spoof packets, or spoof a driver's license, etc.
And, spoofing control signals from a server to the clients would likely be done with a spoofed packet.
But it's just a problem of looking at the application of a term in our context rather than the larger meaning of the term.
Well, ignoring the law breakings comment (which I assume was a joke,) while they might claim the right to use articles posted in a thread specifically created to solicit material for the new article, I highly doubt they would try (and it wouldn't work if they did) to claim ownership of those copyrights. Until, at least, the person who originally said those things contacts them and sells them the rights. (Which will probably be what their default argeement for compensation is.)
Modal (context sensitive) interfaces are good, as long as you aren't locked into the mode the program uses as default.
ctrl-x/c/v are great cut and paste commands, but I wouldn't want Quake 3 to interpret them that way in the middle of a firefight.
Besides, a good system that, for instance, used '/' to pop up a command window to execute the following keystrokes, could, in a context where '/' is part of the possible input, change '/' to 'ctrl-/' or '\'... Not as handy as the default control, but still easy to get to. That way you don't handicap the interface in one area just to make it compliant to the rest of the interface.
Most chords require the use of two or more typing fingers, and take a fairly long time to hit, for you to be sure you hit the keys in the right order (alt-s is different than s-alt).
The more complicated the chord, and the more finicky the timing (ie, key1 before key2, and hold both until key3 is hit and released) the more it distracts from the goal of getting out as many characters as possible in as short a time as possible.
What would be ideal is for systems to have both a chorded system that opens the menus, much like Alt on a windows system will select (and alt will open) the first menu. Then a novice, or someone entering a less used command gets visual guidance as they enter the command. Other commands could, in a context sensitive way, use / to signal a string of command letters. Then you could type them in as fast as possible.
Really? You've seen the source for the 390 OS and all other IBM OSes, and you don't see ANYTHING in common?
It's a little hard to believe.
It does come down to a matter of faith, but I find it easier to accept that like the hardware which is in continual evolution, each machine building on the ideas of the previous, that the OS itself is based on previous versions.
This survery isn't something people are too likely to lie about. It's not like a Kensey survey, or a political survey asking a sensitive question.
Why would users of one card choose not to send this information to id? And, if all TNT users did decline to, they'd deserve to have lousy driver support. The issue of having to keep something like this secret for it to be effective is obviously irrelevant.
I think we can all trust id, I don't think the issue of Carmack's reliability came up. But... If we accept one company looking for any sort of data behind our backs, then we open the door for companies like Real, or ones doing what Blizzard did.
Don't forget, Quake3 is going to have a CD Key that must be authorized to play online, so they'll have statistics (if they decide to collect them) on how often each copy is played, and from which IPs. A little perl script to check static IPs (@home, etc) with copies of Q3, and which video card was used, would help them find copies used on more than one computer. And then there are the marketting possibilities...
And all of that is if they only take hardware info... If they look for machine IDs, or email addresses, they could easily build a seriously offensive database, all under the guise of tech support.
So we need to let developers know that collecting ANY information is something the user MUST be told about and opt into. If they want to make it a 'do it or don't use the game' then fine, as long as they state it on the box so a user knows before they get home. But we can't let anyone browse our hard drives or collect hardware profiles because when a company is collecting data, it's such a thin line to stealing data.
Yes, but what I mean, is that the OS didn't magically appear, ready to run a mainframe. They took the older OSes, took the parts that worked, junked the rest, and rewrote it for the new hardware.
So yes, it was written for a 390, but I highly doubt they did it from scratch.
So, at no point did a mainframe-capable OS appear out of thin air, so I see no reason why taking a scalable and robust PC OS, you can't use at least a fair bit of it in a mainframe OS. Sure, the I/O stuff, and other similar low-level bits will have to go, and be replaced with something designed for the hardware, but that happens with the same OS between different hardware anyway.
And their longstanding OS experience and the fact that they made the hardware, will let them accomplish the transition fairly easily.
How is one set of code unable to run on a mainframe, and another able to do it?
Do they have to include ?
The OS the S/390 runs was unable to run on an S/390 until someone ported it, and was unable to take advantage of the features until someone coded in support.
So why can this be done with one OS and not with another? It's not like Linux has a GUI built in at the kernel level or anything.
And, I'd think conventional Linux and a mainframe OS would be more similar than the Realtime Linux someone made.
A convergence of OSes is a good thing as should be encouraged. If Linux gets properly ported to the S/390 (as in, works as well as what is there already) then a lot of that code could be folded back into the main branch, perhaps helping stability and scalability to other platforms.
Just think of the benefits of being able to take code written on a PC and transparently drop it on a mainframe. Your developers could work on PCs, testing code there and then simply by recompiling the code, make it run on a mainframe. What better way to bring legacy systems up to date?
But, the Mac isn't any better at anything that Windows, or BeOS, or (asside from setup) Linux with X...
The reason a lot of graphics stuff is still done on the Mac is just inertia from when it was better. That'd be like not using Linux with X because the UNIX system you used in the early 80s was CLI only...
There are some applications, like the real-time one you mentioned, and extremely tiny embedded one, which wouldn't need or work well with even a stripped down version of a real OS, but those are fairly few and far between. And I was talking about computers. Everything from a large organizer to a super computer. Not toasters or temperature probes.
It just seems to me that the days of an OS as a 'product' where you want to buy one because it's better than the others are looking like they'll soon be over. And we should encourage this. If we end up with an open source OS, it won't stifle innovation like having a single closed source OS would.
I like a lot of BeOS's features, but imho they're completely useless to me until they completely pass Linux and Windows in functionality. To me, rebooting into a different OS to use a different program is a terrible reminder of the late 80s, and I hoped to never have to do it again. So until something passes either of the OSes I use on my two computers, I'm not going to switch.
I may try BeOS some weekend when I'm not working, but I'm not going to use it, no matter how nice it is, until I can boot into it and stay there. And until it's got the applications, etc...
Sometimes imperfect standards are here to stay. We no longer use base 60, but we use a 12/24 hour, 60 minute clock. The width of train tracks wasn't decided by technical considerations, but by which company won the war. The QWERTY layout wasn't designed for speed or usability (even if you don't agree DVORAK is faster, you must admit QWERTY is designed to be bad.)
So, rather than reinventing a system just because part of the existing one doesn't work properly doesn't seem to be the way to go. Instead, fork off a dev branch, fix the feature, and get it folded back in as an option that people are encouraged to try. Eventually, the broken 'feature' will go away.
And this is where I see OSes. They're mutually exclusive; if I run two OSes I need to make sure they'll interoperate, and that my applications are available on both. If I patch client software I write, I need to make sure two versions get upgraded. I also can't (without a kludge like running one inside VMWare) run two at once. So it's an either-or proposition.
But, if all the effort was put into building one good free OS that nobody owned (could proprietize and take away) then we'd all benefit because we'd have one OS to run that would work on all the platforms, and so not require special programs (SAMBA) to enable interoperability.
One difference with using identification to buy beer for instance, is that you can hold your fingers over everything on the ID except the picture and the birthdate.
I do this as a general practice. Ditto when someone wants to see another piece of ID and my SIN (SSN) card is all I have. I show them my name on it, but cover the number.
But, the whole idea of needing a license to use the internet seems wrong. All needed audit trails should be kept by your ISP. If you hack into something, your IP will be recorded and your ISP should be able to match that up with who used that IP at that time.
In most other ways, the internet is like using a telephone or postal mail. You send information to someone, and they send information back if they decide to. The main difference is that you can't send mail bombs (physically hurtful packages) in email.
So, requiring a license, with is the governments way of making sure that people have insurance and have trained, etc, isn't really relevant.
Re:But *programmers* should be licensed...
on
License to Surf
·
· Score: 2
No. Programmers are *never* directly responsible for patients lives, or in any other similar situation.
I'm sure many bad products have gone out where the critical routine was looked at only by the author, but that's not that programmer's fault, that's the fault of the company who didn't have at least one other person audit the code and test it.
(I think that having programmers test the program they have source for is as valuable as having end-user level testing. Programmers can try to exploit buffer overflows, improper type checking on input, and many other things that wouldn't occur to an end-user. But, similarly, end users should be used to test the bulk of the program, looking for things the programmers wouldn't think to check for.)
The greatest engineering disasters of our time haven't come from incompotent engineers, or murderous one, they've come from perfectly compotent engineers who simply drew a bolt incorrectly, or left out a safety device on one of fifteen pages, intending to draw it in later.
Those aren't the actions of people needing to be regulated, those are the actions of people who simply need a bit of peer review.
And a company that doesn't give it to them should be liable. But not the engineer or programmer themselves.
So, you're saying that a minor can violate copyrights without any problems? So, there's no legal reason why Billy can't pirate games?
If the copyright has force, then the GPL rests on the agreement that you will do something in trade for the rights to the code.
The kid would be able to use GPL code, because the GPL doesn't prevent usage in any way.
But, the offer is made with the implicit assumption that the other party is capable of entering a contract.
If a car dealership prints a price on a car, you can make them sell you the car for that price because this is equivalent to you asking for a price, and them telling you. But, a minor could not get that car because the dealership wouldn't have made the offer to a minor.
So, no valid offer was extended to the minor, thus they can't enterer into a voidable contract, and they have no permission to rerelease the source code in any form.
This owuld be different if they asked for and received permission, because then the contract would have been intentionally extended to them despite their age.
But, even then, once they void the contract, the other party isn't held to their end anymore, except for whatever was due before the voiding.
Example, if a minor made payments, getting one item (volume on an encyclopedia) per payment, they could void the contract at any time and you would owe them any paid for but as yet undelivered volumes, but you wouldn't owe them the rest of the volumes. But, you wouldn't be able to hold any penalties against them.
This is why all (sensible) business for nonessential items with minors is done in a cash-up-front manner.
Actually, at least in Canada, minors can be held to contracts for necessities like shelter, food, etc.
This was because if you couldn't hold a minor to these things, minors would be unable to buy food, rent an apartment, etc.
If a minor could walk into a restaurant, eat, and leave without paying, legally, restaurants would, of course, stop serving minors without an adult.
So, minor can be held to these contracts.
I would imagine the USA has a similar rule.
BTW, the kid who wrecked the car would be out of luck because when he handed you the money an took the keys/papers, the contract was finished. He could get out of payments, but he couldn't get back the money he had already paid.
I've always taken it to mean that an Alpha is the first version that does 95% of what it has to do and is stable enough to send to an internal tester without a programmer standing behind them telling them not to click on certain things.
And a beta would be when it's stable enough to send out for user comments, not be necessarily stable enough for them to consider using regularly.
I'd call Mozilla a late Alpha, or early Beta now.
The terms have gotten twisted in the last few years, mainly in my opinion, by Microsoft. MS has had OSes at a nearly-ready stage for years, and uses Beta to mean, it's done, but if it crashes, that's cause it was a Beta.
To me, a beta is something you don't run on anything mission critical. I wouldn't use a truly Beta OS on even my PC.
So, I think Mozilla is in Beta now, or would be if the terms hadn't changed to justify clumsy bloatware.
Slashdot Mirror
Ok, I'll clarify a little.
I still don't think most of the work is 'art' and I don't believe that what 95% of people do couldn't be done by a replacement just as easily.
I'm sure there are a few jobs that the public wouln't recognize that are a black art, that you can't train someone in, they have to apprentice and pick it up by osmosis, and I'll even grant that some of these jobs might be important to the final quality the film.
But, I'm sure these are few and far between. For every focus puller there are ten assistants to the stars, who are being listed more and more often, and caterers, etc.
Why am I sure? What's my vast experience in the theatre industry? Zip. I admit that. But I've worked a lot of jobs and seen that it's very rare more then 10% of the people in a company actually work on the final product, everyone else just supports the people who do. I don't imagine hollywood, which is about money, not art, at least at any big studio, is any different. (At least, this is how the money end sees it, I'm sure the workers usually see it as more than just another movie.)
I've even had a gopher job. I did incredibly dull stuff and waited on my boss. I took phone calls, did minor paperwork, got coffee, etc, all so she could keep working. And I'm sure she got more work done because of it... But, I don't think that I influenced the quality or design of her work, just the ammount of it. And I could have been replaced by any equally trained gopher who would have been just as helpful to her. If someone had asked about her work, should I have volunteered that I helped make it? Should it have been in my contract with her that I must get mentioned?
And I'm not making the assumption that because I don't understand it, it must be easy. Some of what I did took months before I could do a single task as well as she could. And I also wrote custom tracking software, and did many other non-trivial things. But, I still didn't produce the final product. She did. If I was sick, work went on. When I eventually left, work went on.
And it's not like this is an amateur play where the support staff does it out of the good of their hearts. This is payed work. The same thing almost everyone else does every day.
To me, credits are a way of finding out who did something in the movie that you saw and liked. Actors names are listed so you can identify them. The director is listed, as are many of the important FX people so you can identify their work. But, if a job doesn't affect the quality of the movie directly, it is unimportant to the audience.
It doesn't really matter. The contracts are already written, and the film cost is negligible compared to the length of the movie. I'm not campaigning to wipe out credits, just to explain why I, and obviously a lot of other people, feel the way I do about them.
I didn't mention legal issues because I was talking about codecs.
As in, you don't really need to hammer out all of the possible video formats, as long as there's a way to describe the format to the player (a codec) supplied on the disc or accessible on the net, etc.
This is like a player which understands MPEG files getting a disc with an AVI (for example) on it. The disc could include the codec, or a URL to download it. The player could either cache this codec in NVRAM, or simply load it everytime it was needed.
As for the legality... pretty much everything involving copyrights is now illegal, or will be as of the new year, in the USA. The Digital Millenium act really screwed you guys over.
But, even so, if it was designed properly and players had a large secret key that they could use for authentication, yes, you could run a system where the player not only downloaded the actual decryption system, but also an encrypted (for its secret key only) key which would allow viewing of the disc.
But, I think that any form of authentication being needed to view a copyrighted work for which you paid to be able to view, is evil. It's like DIVX... you have the right to view the content only as long as the company says you can, in the way they want, and while they are in business.
Sure. If they're free, why the hell not.
But they're annoyingly PC. Gone are the days of credits being for people who actually did something. Now you've got to include everyone in the department, if not their families.
The grips of the world, and their office counterparts, who do jobs that need to be done, but who don't have any effect on the final product simply don't need to be listed.
If the movie or software credits were carried into other fields, you'd see companies crediting their janitorial staff alongside their engineers for new consumer electronics.
Maybe it's a great way to pacify the workers, but that doesn't mean it makes sense.
Actually, including that many credits in the movie WOULD increase ticket price, seeing as the credits do take up film, and studios always bitch about how expensive film is. But, that's pretty well offtopic.
Including people who aren't involved in acting, directing, or creating sets/effects, distracts from the listing of the people who actually affected the movie/couldn't be replaced with temp workers.
It may be cool for you to have your name listed, but do you honestly expect people to believe that you affected the final movie in any way? If those cords hadn't been taped a certain way, that scene just wouldn't have worked?
So, you include 40,000 names. Wow. That's going to be exciting to read. Nobody, not even the obsessive types who've posted in this thread, would stay to read that, it'd be like reading a phonebook.
And are the names meaningful? Are they simply an alphabetic listing of everyone who worked at the company during the product development, or do you list people in order of importance?
Listing actors above grips is appropriate in a movie because actors (unfortunately) are a commodity. People pay to see films starring a certain actor even if they wouldn't have watched the film otherwise. The same isn't true about the grip, the makeup staff, etc.
But, with software (with the exception of some people buying anything John Carmack writes for instace...) you buy the product because of what it is (or what it does) not because of who wrote it.
In this case, the lead programmer (who probably spent most of his time in meetings) is less important that the grunts who slaved away writing the actual thing. So how do you justify listing the lead programmer above the grunts? There are no accurate ways to determine who to list. (Look at the argument surrounding how to judge a programmer's output.) So you either piss off half the staff by listing some ass-kissing management guy first, or ruin the list by simply making it an alphabetic list of names.
The alphabetic list of names might work for small projects, less than a hundred or so people, when the people listed could easily point their name out to friends. But what about a product like MS Office, or Mac OS X... I wouldn't doubt that five or ten thousand people helped in some way to make those products.
So, lacking a fair and interesting way to list the credits, I agree with the decision to scrap them.
Or, as I said earlier, replace them with a 'team credit', where the particular dev team gets to make their own logo and display that...
Probably irrelevant. General purpose computers are getting so cheap that by the time a format capable of replacing DVD (offering actual improvements) came around, the players would probably be integrated with a computer. (Even if the user didn't have a monitor and didn't ever explore that aspect of the device.)
So, as long as there was a filesystem on there, the format of the files is fairly unimportant as long as it's not proprietary.
Then if the disk needed a specific codec, it could simply ship with it, or the computer could grab it off the net.
And a general purpose computer would be able to understand that a raw image at 128khz, 64b is the same basic thing as 44khz, 16b, and use the same codec with different parameters, thus pleasing audiophiles who demand every last irrelevant bit be the same, and pleasing techies to whom a VBR MP3 is more appropriate.
On a slightly offtopic rant...
It pisses me off when people demand uncompressed audio of incredibly high data rates. Sure, some piece of music might benefit from having that fidelity at one point, but at all others, it's wasted. The appropriate design would use whatever bandwidth was available and use lossy compression. If that signal needs to be reproduced, then do so, but don't waste the bandwidth by representing all data equally when some is obviously more important.
For any digital lossless compression, a smart encoder could produce a better representation of the original by encoding a higher quality initial signal in the same space.
For an install disk. Well, not for a few years. Five maybe.
Graphics are HUGE. Movies are even bigger.
When everyone is playing games in 2048x1536x32b, and games have to either have tons of textures, or in the case of top-down games, tons of distinct landscapes, we'll be looking at 140GB and complaining that it's not enough.
A flight-sim could use this already. As could a decent off-road driving game.
And as it becomes available, people will use it, precalculating huge data structures to save themselves the trouble of doing it on the fly. (It's not always a bad thing... Quake's BSP trees are precalculated.)
140 hours of video could allow for a kick-ass interactive movie. Imagine if there was actually room to store alternate paths for a bunch of different decisions.
I've had the idea of, when space allows, including a map of all roads in North America (all roads mapped in electronic format at any rate) and not only pictures of actual building near the road, but a rough map of the land nearby. Imagine a driving game like Cannonball Run, where you aren't looping around some dull track, but the game starts in one city and ends in another, and all paved roads in both are in the game. Combine that with textures 3d models of the main buildings and landscaping that you can see from the road. Then further imagine you had the ability to go cross country, cutting across fields as a shortcut.
If storage wasn't a problem, the modelling/texture mapping could be handled with a GPS, a decent laser range finder, a high res digital camera, and some software. Toss it into a van and drive slowly around the area. The GPS knows where you are, space around you would be mapped with the laser, and buildings photographed for the textures. Simply things like light posts could even be identified and replaced with stock models.
It's beyond or capabilities now, but I bet in five years, EA Sports will be seriously considering it.
You're talking about that thing that was later included in the MS screensavers, right?
The 2d maze with 90 degree walls and low-res textures?
That's a long way from a doom client.
Any decent demo coder could whip something like that up in under 4k, 8k if it required textures.
Alright, so MS probably did it in VB and took a few megs, but it's not like they actually stuck Doom in there.
As an example... I saw a 4k demo with music (only on a GUS I believe) which was basically a flyby of the first level of Descent 1, without robots or the reactor, and some level simplification. But it didn't use 90 degree walls, wasn't 2d, wasn't slow...
It was a really cool example of demo coding, and was one of the best examples that demos aren't irrelevent. They basically duplicated the rendering loop of Descent in 4k of assembly. (portal rendering systems are fairly easy to do.)
If anyone has this demo, maybe they can uuencode it and post it, it's small enough to not cause a problem.
Do you read them all, caring about the name of the grip, or do you do it looking for the odd joke, and waiting till the theatre empties?
Movies have the same problem software is starting to have. Way too many people to list. You either list just the big names, thus pissing off people who didn't make the cut, or you list everyone, drowning out the names of the important people, or you go with the minimum, ie those people whose union contracts require them to be listed.
In my opinion, listing grips and other people in movie credits is ridiculous. Their influence is insignificant, and doesn't take any 'art', they could be easily replace by anyone else trained in the field and the work wouldn't suffer.
If you start listing everyone in software projects, either you get insanely long lists, which have to be alphabetically sorted (to avoid fights over priority) and include everyone from the lead programmers down to temporary data entry staff, or you get arbitrarily short lists and piss people off.
A company like id software can do it, because they have few enough employees, and all of them (even, so they say, their secretary/mom) have enough influence on the project that listing them isn't a joke. But this is because they have less than twenty people involved in actually making the game.
And even then it's a stretch. They aren't mentioning any of the testers, famous ones like Thresh, or anonymous ones at Activision, or (I think) the guy who now maintains the eiting tools, etc.
So, being that any attempt to list credits in a company with more than 20-30 people is going to be flawed, I think it's something that should best be left out.
What they could do, if they make feel team spirit, is to code some cool effect, and use the team's internal codename (if they have one.) Thus getting an easter egg, and team pride, without the task of having to name each and every person at all responsible in such a way that wouldn't piss anyone off.
The 'lamp' could really be anything electrical that wouldn't be placed in a closet.
If a PC was tampered with to make it listen for a network connection on the IR port, then you could do anything on the larger network that the PC could. And the 'lamp' could rebroadcast the weak signal with enough power to reach a station across the street, or in some other unsecured area, where the attacker could setup a more robust phone or cellular connection to the actual hacking base station.
And, a lamp would be a good thing to stick an IR rebroadcaster in for a number of reasons. Lamps are fairly electrically noisy, a sweep of the room with an inductive amplifier wouldn't pick up the rebroadcaster because of the 'noise' of the lamp. Lamps are also a fairly common, and come in endless styles. A lamp suitable for an IR rebroadcaster (one with IR transparent plastic on the base) could be easily found and wouldn't look too out of place.
As someone else said, this attack doesn't need to be made on the server, or in the server room. All you need is some non-techy who has access via the network to the information you want. Or, has access to something that will through hacking, allow you to gain further access.
Lamps are great because they're the least technical, and thus the most likely to function properly, electronic device present on most desks.
I think the idea is a little far fetched, but that's probably because most of the security I deal with is for my company and at most, our data is orders of magnitude less important (financially) than fund transfers, making an attempt with a high initial cost and moderate risk (physical intrusion), very unlikely.
Spoofing only refers to packets in our context, that of network types.
But, a spoof (a hoax) is a trick of any type to substitute something fake for something real. You could spoof packets, or spoof a driver's license, etc.
And, spoofing control signals from a server to the clients would likely be done with a spoofed packet.
But it's just a problem of looking at the application of a term in our context rather than the larger meaning of the term.
Well, ignoring the law breakings comment (which I assume was a joke,) while they might claim the right to use articles posted in a thread specifically created to solicit material for the new article, I highly doubt they would try (and it wouldn't work if they did) to claim ownership of those copyrights. Until, at least, the person who originally said those things contacts them and sells them the rights. (Which will probably be what their default argeement for compensation is.)
Because he at least tried... They posted a previous article for comments, and solicited help in fixing it.
They should have gone the next step, posting the finished article for proof reading... But, can't expect them to get it right the first time.
Modal (context sensitive) interfaces are good, as long as you aren't locked into the mode the program uses as default.
ctrl-x/c/v are great cut and paste commands, but I wouldn't want Quake 3 to interpret them that way in the middle of a firefight.
Besides, a good system that, for instance, used '/' to pop up a command window to execute the following keystrokes, could, in a context where '/' is part of the possible input, change '/' to 'ctrl-/' or '\'... Not as handy as the default control, but still easy to get to. That way you don't handicap the interface in one area just to make it compliant to the rest of the interface.
Chords aren't really bad, but they aren't great.
Most chords require the use of two or more typing fingers, and take a fairly long time to hit, for you to be sure you hit the keys in the right order (alt-s is different than s-alt).
The more complicated the chord, and the more finicky the timing (ie, key1 before key2, and hold both until key3 is hit and released) the more it distracts from the goal of getting out as many characters as possible in as short a time as possible.
What would be ideal is for systems to have both a chorded system that opens the menus, much like Alt on a windows system will select (and alt will open) the first menu. Then a novice, or someone entering a less used command gets visual guidance as they enter the command. Other commands could, in a context sensitive way, use / to signal a string of command letters. Then you could type them in as fast as possible.
Really? You've seen the source for the 390 OS and all other IBM OSes, and you don't see ANYTHING in common?
It's a little hard to believe.
It does come down to a matter of faith, but I find it easier to accept that like the hardware which is in continual evolution, each machine building on the ideas of the previous, that the OS itself is based on previous versions.
This survery isn't something people are too likely to lie about. It's not like a Kensey survey, or a political survey asking a sensitive question.
Why would users of one card choose not to send this information to id? And, if all TNT users did decline to, they'd deserve to have lousy driver support. The issue of having to keep something like this secret for it to be effective is obviously irrelevant.
I think we can all trust id, I don't think the issue of Carmack's reliability came up. But... If we accept one company looking for any sort of data behind our backs, then we open the door for companies like Real, or ones doing what Blizzard did.
Don't forget, Quake3 is going to have a CD Key that must be authorized to play online, so they'll have statistics (if they decide to collect them) on how often each copy is played, and from which IPs. A little perl script to check static IPs (@home, etc) with copies of Q3, and which video card was used, would help them find copies used on more than one computer. And then there are the marketting possibilities...
And all of that is if they only take hardware info... If they look for machine IDs, or email addresses, they could easily build a seriously offensive database, all under the guise of tech support.
So we need to let developers know that collecting ANY information is something the user MUST be told about and opt into. If they want to make it a 'do it or don't use the game' then fine, as long as they state it on the box so a user knows before they get home. But we can't let anyone browse our hard drives or collect hardware profiles because when a company is collecting data, it's such a thin line to stealing data.
Yes, but what I mean, is that the OS didn't magically appear, ready to run a mainframe. They took the older OSes, took the parts that worked, junked the rest, and rewrote it for the new hardware.
So yes, it was written for a 390, but I highly doubt they did it from scratch.
So, at no point did a mainframe-capable OS appear out of thin air, so I see no reason why taking a scalable and robust PC OS, you can't use at least a fair bit of it in a mainframe OS. Sure, the I/O stuff, and other similar low-level bits will have to go, and be replaced with something designed for the hardware, but that happens with the same OS between different hardware anyway.
And their longstanding OS experience and the fact that they made the hardware, will let them accomplish the transition fairly easily.
How is one set of code unable to run on a mainframe, and another able to do it?
Do they have to include ?
The OS the S/390 runs was unable to run on an S/390 until someone ported it, and was unable to take advantage of the features until someone coded in support.
So why can this be done with one OS and not with another? It's not like Linux has a GUI built in at the kernel level or anything.
And, I'd think conventional Linux and a mainframe OS would be more similar than the Realtime Linux someone made.
A convergence of OSes is a good thing as should be encouraged. If Linux gets properly ported to the S/390 (as in, works as well as what is there already) then a lot of that code could be folded back into the main branch, perhaps helping stability and scalability to other platforms.
Just think of the benefits of being able to take code written on a PC and transparently drop it on a mainframe. Your developers could work on PCs, testing code there and then simply by recompiling the code, make it run on a mainframe. What better way to bring legacy systems up to date?
But, the Mac isn't any better at anything that Windows, or BeOS, or (asside from setup) Linux with X...
The reason a lot of graphics stuff is still done on the Mac is just inertia from when it was better. That'd be like not using Linux with X because the UNIX system you used in the early 80s was CLI only...
There are some applications, like the real-time one you mentioned, and extremely tiny embedded one, which wouldn't need or work well with even a stripped down version of a real OS, but those are fairly few and far between. And I was talking about computers. Everything from a large organizer to a super computer. Not toasters or temperature probes.
It just seems to me that the days of an OS as a 'product' where you want to buy one because it's better than the others are looking like they'll soon be over. And we should encourage this. If we end up with an open source OS, it won't stifle innovation like having a single closed source OS would.
I like a lot of BeOS's features, but imho they're completely useless to me until they completely pass Linux and Windows in functionality. To me, rebooting into a different OS to use a different program is a terrible reminder of the late 80s, and I hoped to never have to do it again. So until something passes either of the OSes I use on my two computers, I'm not going to switch.
I may try BeOS some weekend when I'm not working, but I'm not going to use it, no matter how nice it is, until I can boot into it and stay there. And until it's got the applications, etc...
Sometimes imperfect standards are here to stay. We no longer use base 60, but we use a 12/24 hour, 60 minute clock. The width of train tracks wasn't decided by technical considerations, but by which company won the war. The QWERTY layout wasn't designed for speed or usability (even if you don't agree DVORAK is faster, you must admit QWERTY is designed to be bad.)
So, rather than reinventing a system just because part of the existing one doesn't work properly doesn't seem to be the way to go. Instead, fork off a dev branch, fix the feature, and get it folded back in as an option that people are encouraged to try. Eventually, the broken 'feature' will go away.
And this is where I see OSes. They're mutually exclusive; if I run two OSes I need to make sure they'll interoperate, and that my applications are available on both. If I patch client software I write, I need to make sure two versions get upgraded. I also can't (without a kludge like running one inside VMWare) run two at once. So it's an either-or proposition.
But, if all the effort was put into building one good free OS that nobody owned (could proprietize and take away) then we'd all benefit because we'd have one OS to run that would work on all the platforms, and so not require special programs (SAMBA) to enable interoperability.
One difference with using identification to buy beer for instance, is that you can hold your fingers over everything on the ID except the picture and the birthdate.
I do this as a general practice. Ditto when someone wants to see another piece of ID and my SIN (SSN) card is all I have. I show them my name on it, but cover the number.
But, the whole idea of needing a license to use the internet seems wrong. All needed audit trails should be kept by your ISP. If you hack into something, your IP will be recorded and your ISP should be able to match that up with who used that IP at that time.
In most other ways, the internet is like using a telephone or postal mail. You send information to someone, and they send information back if they decide to. The main difference is that you can't send mail bombs (physically hurtful packages) in email.
So, requiring a license, with is the governments way of making sure that people have insurance and have trained, etc, isn't really relevant.
No. Programmers are *never* directly responsible for patients lives, or in any other similar situation.
I'm sure many bad products have gone out where the critical routine was looked at only by the author, but that's not that programmer's fault, that's the fault of the company who didn't have at least one other person audit the code and test it.
(I think that having programmers test the program they have source for is as valuable as having end-user level testing. Programmers can try to exploit buffer overflows, improper type checking on input, and many other things that wouldn't occur to an end-user. But, similarly, end users should be used to test the bulk of the program, looking for things the programmers wouldn't think to check for.)
The greatest engineering disasters of our time haven't come from incompotent engineers, or murderous one, they've come from perfectly compotent engineers who simply drew a bolt incorrectly, or left out a safety device on one of fifteen pages, intending to draw it in later.
Those aren't the actions of people needing to be regulated, those are the actions of people who simply need a bit of peer review.
And a company that doesn't give it to them should be liable. But not the engineer or programmer themselves.
So, you're saying that a minor can violate copyrights without any problems? So, there's no legal reason why Billy can't pirate games?
If the copyright has force, then the GPL rests on the agreement that you will do something in trade for the rights to the code.
The kid would be able to use GPL code, because the GPL doesn't prevent usage in any way.
But, the offer is made with the implicit assumption that the other party is capable of entering a contract.
If a car dealership prints a price on a car, you can make them sell you the car for that price because this is equivalent to you asking for a price, and them telling you. But, a minor could not get that car because the dealership wouldn't have made the offer to a minor.
So, no valid offer was extended to the minor, thus they can't enterer into a voidable contract, and they have no permission to rerelease the source code in any form.
This owuld be different if they asked for and received permission, because then the contract would have been intentionally extended to them despite their age.
But, even then, once they void the contract, the other party isn't held to their end anymore, except for whatever was due before the voiding.
Example, if a minor made payments, getting one item (volume on an encyclopedia) per payment, they could void the contract at any time and you would owe them any paid for but as yet undelivered volumes, but you wouldn't owe them the rest of the volumes. But, you wouldn't be able to hold any penalties against them.
This is why all (sensible) business for nonessential items with minors is done in a cash-up-front manner.
Actually, at least in Canada, minors can be held to contracts for necessities like shelter, food, etc.
This was because if you couldn't hold a minor to these things, minors would be unable to buy food, rent an apartment, etc.
If a minor could walk into a restaurant, eat, and leave without paying, legally, restaurants would, of course, stop serving minors without an adult.
So, minor can be held to these contracts.
I would imagine the USA has a similar rule.
BTW, the kid who wrecked the car would be out of luck because when he handed you the money an took the keys/papers, the contract was finished. He could get out of payments, but he couldn't get back the money he had already paid.
I've always taken it to mean that an Alpha is the first version that does 95% of what it has to do and is stable enough to send to an internal tester without a programmer standing behind them telling them not to click on certain things.
And a beta would be when it's stable enough to send out for user comments, not be necessarily stable enough for them to consider using regularly.
I'd call Mozilla a late Alpha, or early Beta now.
The terms have gotten twisted in the last few years, mainly in my opinion, by Microsoft. MS has had OSes at a nearly-ready stage for years, and uses Beta to mean, it's done, but if it crashes, that's cause it was a Beta.
To me, a beta is something you don't run on anything mission critical. I wouldn't use a truly Beta OS on even my PC.
So, I think Mozilla is in Beta now, or would be if the terms hadn't changed to justify clumsy bloatware.