We wanted web pages to control the spellchecking defaults to some degree. For example, webmail applications will want to automatically turn it on for subject lines, even though it is normally off for <input> elements.
We discussed with the WHATWG web standards group to come up with the attribute. I'm not sure about the status of this in any of their specs, as I'm not sure there was any strong consensus. That's one of the problems coming out with a new feature not currently supported in any other browser or mentioned in any standards.
You can copy the very obviously named bookmarks_history.sqlite just the same way. Not surprisingly, this file contains the profile's bookmarks and history. It might also have a corresponding.journal file (if the previous run crashed) which you'll need. Did you think there would be some kind of secret storage that can't be copied?
To answer some other people's question: there will probably be some kind of bookmarks.html export in the final version if you want to just back up the bookmarks or want to transfer the bookmarks somewhere else.
I agree that toolbars are a waste of space. Which is why I think the best feature of this new version (which I haven't seen mentioned here yet) is support for the toolbar customize palette.
Right-click on any toolbar and go to customize. Now you can drag your favorite buttons from the Google toolbar onto your regular toolbar. Now, *turn off* the Google toolbar.
You don't seem to understand the modern rendering workload. Its all I/O. A typical frame of geometry (>10GB) won't even fit into most memories, much less the textures which are often orders of magnitude larger. This is not your typical game or raytracer which loads everything in a couple seconds at the beginning and spends half an hour crunching numbers. Tremendous effort is spent paging stuff in and out and keeping memory from overflowing. Also keep in mind that it needs to probably be sucked over the network in the first place.
Having the additional address space of the 64-bit system will help a lot, as will the high throughput of the G5.
The Opteron may make sense here as well, but the software isn't mature enough yet for them to be able to run all the systems on it. Windows doesn't support the 64-bit yet, of course, and Linux stuff varies. For example, they presumably will want good 3D acceleration for the modeling if they really want to be able to use a certain system uniformly in their operation, and the performance of Linux 64-bit 3D drivers isn't up to the traditional x86 yet (and often won't even work if you have >4GB RAM).
Coding: People here are complaining that coding is classified as a "low-level" job. A lot of companies have been treating coding as a low-grade skill for quite some time. A team of high-level people design the thing, and they hand it off to the lowest-paid workers that can actually implement it. These low-level American jobs purposefully don't leave much room for creativity, and the pay is not really that great. Outsourcing those jobs to India is merely a continuation of this trend and follows the manufacturing sector where the jobs of feeding the machines and putting stuff in boxes have mostly gone to China.
Management: A lot of/.-ers are complaining about how management sucks and how its so much easier than programming. This is false. Management is really hard and takes a lot of skill. Most mangers suck, of course, but most programmers suck, too. You never notice the rare good manager who takes mediocre programmers and makes a successful project, but a bad can have great programmers and get nothing done (of course, of you have genuinely bad programmers, you're screwed no matter what). The Indian industry will mature, and a lot of management and design jobs will eventually be outsourced there, too.
Quality: Think about any physical thing you buy. It probably has "acceptable" quality and doesn't cost very much. After a while, you get a different one, which probably has newer and better technology that you wanted anyway. (If everything you bought was a minor masterpiece, you'd pay for it by having out-of-date technology; it's the price of our fast-changing world.) If you want better quality, you have to pay a lot more, and the product, or large portions of it, are much more likely to be made in the US/Canada or Europe. Sure software quality sucks, but mostly it does what people want and is cheap. A lot of people are willing to put up with problems to pay less. In the end, the top software jobs will stay, just like the top manufacturing jobs are still here.
One problem really is that we don't know how to design software in a predictable way. Attempts to design inexpensive software are often more expensive in the end, and trying to do a great job can lead to bloated projects that are never done. Many expensive American projects really suck, and probably some cheap Indian projects are great. The field currently just doesn't have the maturity for us to say with any predictability "if we spend X dollars we will get Y quality." When/if the field reaches the predictability of manufacturing cheap software will be made in developing countries, and great software will be made in mature countries.
Protectionism: While short-term measures can allow an industry to restructure itself and become more efficient, long-term protectionism never works. Consider the recent steel tariffs. I'm not qualified to say if they were the right thing, but the idea was to allow some short-term period for the steel industry to get it together because we all benefit from a competitive industry. A long-term tariff, however, makes American products made from steel products more expensive. American consumers could then buy less, and American products can not be sold overseas.
The same is true for software. India currently specializes in grunt-work coding. Protectionist measures will save some American grunt-coding jobs in the short-term. However, what will happen in 10 years? A fraction of those Indians will get mad skillz. Indian software companies, now with competitive-quality coders, and benefiting from cheaper labor than their American counterparts, will clean up. The American industry will ultimately suffer. Its better for the bad American coders to find a different field or get better skills now than later. Think about it, it may suck to lose your job now, but its worse to lose your job from a dying industry when you're 10 years from retirement and have no recent skills or training.
This was one of the proposals for StarWars in the 80s, except that it would bounce the laser off mirrors on satellites instead of mirrors on airplanes. The problem is, it won't work. One of my physics professors (he was very liberal-minded) proved it for the class.
To have enough power required to do damage the laser has to be very powerful. Even the best mirrors we have today can not withstand that much energy without heating so much they warp to the point that the beam is too diffuse to do any harm. Keep in mind that the mirror has to be very precise to focus a beam on a distant target.
The lasers they use for this type of thing are often too powerful for any kind of transparent window as well. The laser cavity normally has a piece of glass on the end to keep it sealed (or quartz for higher-powered lasers). I don't know about this specific laser, but some of the ground-based lasers they have to shoot down missiles and airplanes use a standing shock wave to seal the end of the laser cavity. Its generated by a special wind tunnel!
If you work as an independent contractor or as a corporation, you will probably have some kind of contract where you have to provide the services requested to get paid. If your code doesn't work as advertised or you want to quit, you will probably be obligated to fix everything or risk being sued (or just not being paid). As an employee, you won't have these kinds of liabilities.
Nobody plans to have problems with a project, but there are a lot of ways for a project to go bad that aren't your fault. You do not want to be in a situation where you have to be fixing bugs for the next 3 years (I speak from personal experience).
As an employee, you get paid at the end of the month. If you do a crappy job maybe you get fired or transfered to another project, but you get paid for the time you spent. Not happy with working at that company? Quit! But you still got paid. If you are a corp or consultant, you are probably obligated to (1) finish the project and (2) do it correctly or risk getting sued or not getting paid.
The decision to make the interface custom was a result of the incredible mess that became of the previous cross-platform version. It is also necessary to provide custom controls to comply with CSS, which allows web pages to define button and scrollbar colors, for example.
IE defines its own controls for this reason (no kidding!), they just look like the Windows ones by default. Microsoft Word (and possibly the rest of Office) have all custom controls that look like the Windows ones. Sometimes the look is slightly off and if you look at the window hierarchy in Spy++ you'll notice that the buttons are not actually Windows, which is what you'd get with native widgets. So people shouldn't single out Mozilla for their criticism of its custom controls.
I used Mozilla on a Mac a while ago and I swear (much to my surprise) that it was using native widgets. Of course, it uses native menus, but the buttons and scrollbars seemed to be native as well, I played with the system configuration and the changes (like for scroll bar button configuration) seemed to be reflected in Mozilla. If this is the case, it should be easy to use native Aqua controls. Can somebody with a Mac confirm this?
I recently had to learn ML (Meta Language) for a class. I'd done some Scheme and Lisp before, and ML at first seemed annoying.
But ML turned out to be great! It functions like Lisp, but has some additional interesting features:
Strong type checking: Most of my Lisp errors were type errors. ML is the most strongly typed language I have heard of (its often used by language theoriticians). When you run the program it is first fully type checked, very few runtime errors are even possible. What makes it different from C is that type checking is implicit (although you can specify types if you want). The compiler/interpreter will figure out which types a function can accept, so you can have a function that accepts many different types for some argument, yet you get the safety of full type checking.
Its simpler than Lisp. Lisp has too much crap thrown in. ML is more understandable (like Scheme).
Few parenthesis. Although your programs are structured similar to Lisp, most parenthesis are not needed, which IMO really helps readability and makes it easier to change (no more counting parenthesis when you add something).
More powerful functions. When you call a function the arguements are actually matched against a pattern in the function declaration. The function with that name which has a pattern that matches the closest is used. You can write interesting recursive functions where one version of the function gets called normally, and another gets called when the argument is a 1, for example. This only scratches the surface of how powerful this feature is.
I went to a presentation on the PS2 architecture by a Sony guy at Berkeley last year. Somebody in the audience asked why the framebuffer was the only thing in the machine that looked small.
The Sony guy said that it was not really a limitation. Portions of the main memory can be mapped to video memory. The video system will then DMA the textures over the (2048 bit wide!) bus and you don't notice that they aren't really in the video memory.
It'll always be slower to go to the main bus, but given that the guy also said the PS2 had more bus bandwith than a big SGI, its probably not much slower.
Later in the license it says "The Software might include source code."
With regard to the people asking about automatically generated code: "Source code which you generate with an Inprise source code generator, such as an Application Wizard, is considered by Inprise to be your code."
Slashdot Mirror
Is this a non-standard attribute?
We wanted web pages to control the spellchecking defaults to some degree. For example, webmail applications will want to automatically turn it on for subject lines, even though it is normally off for <input> elements.
We discussed with the WHATWG web standards group to come up with the attribute. I'm not sure about the status of this in any of their specs, as I'm not sure there was any strong consensus. That's one of the problems coming out with a new feature not currently supported in any other browser or mentioned in any standards.
- Brett (Firefox spellcheck contributor)I don't see any chance of this happening.
Alphas and betas are not shipped in debug mode.
To answer some other people's question: there will probably be some kind of bookmarks.html export in the final version if you want to just back up the bookmarks or want to transfer the bookmarks somewhere else.
Right-click on any toolbar and go to customize. Now you can drag your favorite buttons from the Google toolbar onto your regular toolbar. Now, *turn off* the Google toolbar.
You don't seem to understand the modern rendering workload. Its all I/O. A typical frame of geometry (>10GB) won't even fit into most memories, much less the textures which are often orders of magnitude larger. This is not your typical game or raytracer which loads everything in a couple seconds at the beginning and spends half an hour crunching numbers. Tremendous effort is spent paging stuff in and out and keeping memory from overflowing. Also keep in mind that it needs to probably be sucked over the network in the first place.
Having the additional address space of the 64-bit system will help a lot, as will the high throughput of the G5.
The Opteron may make sense here as well, but the software isn't mature enough yet for them to be able to run all the systems on it. Windows doesn't support the 64-bit yet, of course, and Linux stuff varies. For example, they presumably will want good 3D acceleration for the modeling if they really want to be able to use a certain system uniformly in their operation, and the performance of Linux 64-bit 3D drivers isn't up to the traditional x86 yet (and often won't even work if you have >4GB RAM).
Coding: People here are complaining that coding is classified as a "low-level" job. A lot of companies have been treating coding as a low-grade skill for quite some time. A team of high-level people design the thing, and they hand it off to the lowest-paid workers that can actually implement it. These low-level American jobs purposefully don't leave much room for creativity, and the pay is not really that great. Outsourcing those jobs to India is merely a continuation of this trend and follows the manufacturing sector where the jobs of feeding the machines and putting stuff in boxes have mostly gone to China.
Management: A lot of /.-ers are complaining about how management sucks and how its so much easier than programming. This is false. Management is really hard and takes a lot of skill. Most mangers suck, of course, but most programmers suck, too. You never notice the rare good manager who takes mediocre programmers and makes a successful project, but a bad can have great programmers and get nothing done (of course, of you have genuinely bad programmers, you're screwed no matter what). The Indian industry will mature, and a lot of management and design jobs will eventually be outsourced there, too.
Quality: Think about any physical thing you buy. It probably has "acceptable" quality and doesn't cost very much. After a while, you get a different one, which probably has newer and better technology that you wanted anyway. (If everything you bought was a minor masterpiece, you'd pay for it by having out-of-date technology; it's the price of our fast-changing world.) If you want better quality, you have to pay a lot more, and the product, or large portions of it, are much more likely to be made in the US/Canada or Europe. Sure software quality sucks, but mostly it does what people want and is cheap. A lot of people are willing to put up with problems to pay less. In the end, the top software jobs will stay, just like the top manufacturing jobs are still here.
One problem really is that we don't know how to design software in a predictable way. Attempts to design inexpensive software are often more expensive in the end, and trying to do a great job can lead to bloated projects that are never done. Many expensive American projects really suck, and probably some cheap Indian projects are great. The field currently just doesn't have the maturity for us to say with any predictability "if we spend X dollars we will get Y quality." When/if the field reaches the predictability of manufacturing cheap software will be made in developing countries, and great software will be made in mature countries.
Protectionism: While short-term measures can allow an industry to restructure itself and become more efficient, long-term protectionism never works. Consider the recent steel tariffs. I'm not qualified to say if they were the right thing, but the idea was to allow some short-term period for the steel industry to get it together because we all benefit from a competitive industry. A long-term tariff, however, makes American products made from steel products more expensive. American consumers could then buy less, and American products can not be sold overseas.
The same is true for software. India currently specializes in grunt-work coding. Protectionist measures will save some American grunt-coding jobs in the short-term. However, what will happen in 10 years? A fraction of those Indians will get mad skillz. Indian software companies, now with competitive-quality coders, and benefiting from cheaper labor than their American counterparts, will clean up. The American industry will ultimately suffer. Its better for the bad American coders to find a different field or get better skills now than later. Think about it, it may suck to lose your job now, but its worse to lose your job from a dying industry when you're 10 years from retirement and have no recent skills or training.
To have enough power required to do damage the laser has to be very powerful. Even the best mirrors we have today can not withstand that much energy without heating so much they warp to the point that the beam is too diffuse to do any harm. Keep in mind that the mirror has to be very precise to focus a beam on a distant target.
The lasers they use for this type of thing are often too powerful for any kind of transparent window as well. The laser cavity normally has a piece of glass on the end to keep it sealed (or quartz for higher-powered lasers). I don't know about this specific laser, but some of the ground-based lasers they have to shoot down missiles and airplanes use a standing shock wave to seal the end of the laser cavity. Its generated by a special wind tunnel!
Nobody plans to have problems with a project, but there are a lot of ways for a project to go bad that aren't your fault. You do not want to be in a situation where you have to be fixing bugs for the next 3 years (I speak from personal experience).
As an employee, you get paid at the end of the month. If you do a crappy job maybe you get fired or transfered to another project, but you get paid for the time you spent. Not happy with working at that company? Quit! But you still got paid. If you are a corp or consultant, you are probably obligated to (1) finish the project and (2) do it correctly or risk getting sued or not getting paid.
The decision to make the interface custom was a result of the incredible mess that became of the previous cross-platform version. It is also necessary to provide custom controls to comply with CSS, which allows web pages to define button and scrollbar colors, for example.
IE defines its own controls for this reason (no kidding!), they just look like the Windows ones by default. Microsoft Word (and possibly the rest of Office) have all custom controls that look like the Windows ones. Sometimes the look is slightly off and if you look at the window hierarchy in Spy++ you'll notice that the buttons are not actually Windows, which is what you'd get with native widgets. So people shouldn't single out Mozilla for their criticism of its custom controls.
I used Mozilla on a Mac a while ago and I swear (much to my surprise) that it was using native widgets. Of course, it uses native menus, but the buttons and scrollbars seemed to be native as well, I played with the system configuration and the changes (like for scroll bar button configuration) seemed to be reflected in Mozilla. If this is the case, it should be easy to use native Aqua controls. Can somebody with a Mac confirm this?
But ML turned out to be great! It functions like Lisp, but has some additional interesting features:
- Strong type checking: Most of my Lisp errors were type errors. ML is the most strongly typed language I have heard of (its often used by language theoriticians). When you run the program it is first fully type checked, very few runtime errors are even possible. What makes it different from C is that type checking is implicit (although you can specify types if you want). The compiler/interpreter will figure out which types a function can accept, so you can have a function that accepts many different types for some argument, yet you get the safety of full type checking.
- Its simpler than Lisp. Lisp has too much crap thrown in. ML is more understandable (like Scheme).
- Few parenthesis. Although your programs are structured similar to Lisp, most parenthesis are not needed, which IMO really helps readability and makes it easier to change (no more counting parenthesis when you add something).
- More powerful functions. When you call a function the arguements are actually matched against a pattern in the function declaration. The function with that name which has a pattern that matches the closest is used. You can write interesting recursive functions where one version of the function gets called normally, and another gets called when the argument is a 1, for example. This only scratches the surface of how powerful this feature is.
- There is even an object oriented version: Caml
It is available from Bell labsThe Sony guy said that it was not really a limitation. Portions of the main memory can be mapped to video memory. The video system will then DMA the textures over the (2048 bit wide!) bus and you don't notice that they aren't really in the video memory.
It'll always be slower to go to the main bus, but given that the guy also said the PS2 had more bus bandwith than a big SGI, its probably not much slower.
Later in the license it says "The Software might include source code."
With regard to the people asking about automatically generated code: "Source code which you generate with an Inprise source code generator, such as an Application Wizard, is considered by Inprise to be your code."
Duh.