Next time when writing English sentences, try to put verbs before their adverbs. Especially in light of your attempt at lecturing others on English linguistics. My single misspelling was intentional by the way. Now, here is a task for your cheap time - try to find it!
Well, good engineers use interfaces and publish them for exactly the purpose of interoperation. Google and Mozilla on the other hand may have other things in their head.
F*ck Chrome, Picasa, Google Ads, Google Docs, GMail, Google Analitics, Google Earth, Google Maps, Google Moon, Google Mars, Google This and Google That. And fuck Google. That thing is like seeing a street sign with boobies painted on it on every corner - too nice to ignore, too commonplace to react. Partition that house of happy nerds already, and give each something real to do. Taking over the world by injecting "healthy competition" into every conceivable attractive market niche may be profitable and "beneficial" but honestly, are we not tired of this awful hideous illconceived word - "Google."? I do not need to be awaken to the wonderful choice of even more web browsers, because some nerd up there believes they are doing the world a service. Hey Google, want to do something really useful? Download the Firefox source and start working...
It is not 'ahead of the curve' unless the end of that curve is in a dumpster, the one where all moronic apple gadgets end up. Not everyone likes Apple style, and even fewer can be led to believe one can ever be as fast a typist using a giant wheel. At least because of the ergonomic factors, the travel distance after all is greater with one giant wheel. I type on my keyboard at about 65 words per minute IN ANY LANGUAGE, without using a T9 type dictionary. I seriously doubt the limitations of a giant wheel will ever let me approach that speed, even after getting accustomed to it fully and using the dictionary like the guy in the video seems to be using.
What Apple should do if they feel like innovating, is to put a touch sensitive LCD display instead of the keyboard so that software may render keyboard keys and what not on that display which people can tap on just as they type and tap a regular keyboard. A goddamn wheel may have worked for an iPod which had to have effective song list scrolling but for a general purpose laptop machine it is a third wheel literally.
True, but Linux is a poster child, sort of. It rides on qualities of its own, which justify the "17 years and still lacks features" line:
1) Decentralized development 2) Developers understand that their code is a public property and have to find other ways to profit from their work, which is not always easy 3) Serious hardware vendor support became fashion just a couple of years ago soonest 4) It had to compete with the status-quo software market for most of its lifetime
So - hobbyists scattered all over the planet working on code together, with only 15% working in the office traditional way (Red Hat, Debian etc), not all getting payed for the same kind of work, having to reverse-engineer stuff third of their time on average trying to convince the world they have a genuine offer - pretty much a mess and having enough hands to keep tidying it up is not so bad an achievement still. It could be better indeed, you are right, but in that case I mean it should not have been a POSIX/UNIX style at all. I wont go into that now...
What would be the procedure like then when needing to install an operating system on a pristine primary and single hard drive?
Say you do not have access to CD/DVD reading hardware nor the media itself. Most of Linux distribution installations, not to mention Windows, are prepared for automatic bootstrapping (El-Torito) install.
How do you do it, and is it convenient? I am just curious. Even if you could alter the OS installing procedure to your liking.
As far as I am concerned, the issue outlined above is a good reason SO FAR to keep removable media around. When we have more flexible installers (yes, many Linux distributions HAVE far more flexible installers than necessary, but still) then maybe we can scrap CD/DVD media in favour of hot-swapped terabyte harddrives (already very well doable today).
1. Reuse if a maintained, actively developed component exists that provides the functionality, especially if the component is advertised for reuse - i.e. a library made for linking.
2. Reuse if you know you know less about implementing needed functionality than you plan to spend time and energy learning. Some things do need time to learn, and the mere programming skills do not help much if you are expected to dig into documentation of different standards and hardware specifications.
3. Reuse generally when any solution already exists, because wrapping up a bad component through a flexible interface is better than tightly coupling self-developed component. Later you may replace the mediocre component with a better candidate, but will retain the interface, so minimal changes will be required to your product.
4. Reuse generally, because through wrapping up a piece of foreign code, will give you the benefit of unit-testing, since the chance of even a mediocre foreign component working better than your first attempt to replicate its functionality is fairly high. This gives you two advantages, the one described at 3. and the benefit of said unit-testing.
5. Rewrite if you plan to after-maintain the developed component you otherwise would reuse from somewhere else, especially if you will consider giving it its own life as a standalone generic solution.
6. Runtime linking is teoretically a better idea, however practically, almost every time the version of the linked library changes, the whole product suffers due to degrees of incompatibility with the said library, however promised its version compatibility. This unfortunately happens much to often, one of the reasons many seasoned developers prefer to embed code at compilation time, thus eliminating the runtime incompatibility problem. They make up for it by frequently (or infrequently, pick yours) recompiling and publishing their host product with the updated library version re-compiled into it.
I think 'harder' is improper word here. When a compiler is ready, porting it to another architecture may only make it marginally slower at first, due to challenges in achieving optimization when emitting code for that platform. The compiler logic however is very well shared across platforms, be it flavors of RISC or CISC. A proper word IMO would instead be simply 'more work'. Whether the compiler emits a "jmp" or "mov" or "cmp" instructions, or RISC primitives, it is equally doable. The challenges with developing compilers, JIT included, lie on a higher abstraction level, with finite-state-machines, dependency tree building and accounting for a platforms inability to do certain things that are part of the language (such as structure granularity in C, and how the programs well-behavior may depend on it).
Don't you read, man? There are tons of fine details, credible and verifiable sources that lend far more credibility to the fact that it happened, than your puny excuse for a history lesson you shared with us, however inspiring it may be. Pretty much all evidence points to the fact that a genocide did happen, exact numbers and places varying. Armenian nation counted for around two million by 1915 already, scattered across within the borders of the Ottoman Empire, all the way to the west. There are countless more details, but you seem to be reading all the wrong articles. And it is not only Armenian diaspora doing the research, also Russian, French and English researchers doing their job. Even now the facts continue to unravel, and it sucks more and more to deny it. We can dispute what, were and how much happened, but hundreds of thousands of hungry Armenians forced to march deliberately without food and water into Syrian deserts did die. Extreme or no extreme, Hrant Dink or no Hrant Dink. Peace.
1. No I am not joking. 2. I did not say a million Armenians lived in Ottoman Empire. But they did, because the Armenia itself, their historical land, was part of the Ottoman Empire which at the time engaged Russia right on their (Armenian) land when everybody went trigger-happy as part of WW-I. The point is a million has perished around there. 3. It is very good they live in peace. It is always good. They just played a soccer game, which did not end up in killings like some thought. What is your point here, if you have any? 4. Don't tell me what to read, I do read enough history and more on controversial subjects like this, it appears you are short tempered though. 5.By your logic, if Hitler wished to do holocaust then a lot of nations in Europe would have disappeared by now. They have not indeed, but not because Hitler did not succeed in killing millions others. More could have died, but there is such thing known as opposing force. You have just written a meaningless paragraph, which is even less meaningful as an argument. 6. Many oppressing regimes allowed a good degree of sovereignity for the members of their empires. This did not stop the rulers from brutality on a case by case basis, and Armenians must have really scratched the Ottoman Empires itch.
And also, the fact that over a million Armenians have disappered from the face of the Earth is acknowleged as a fact even more so than the fact that it was a genocide. Additionally, most of U.S. states explicitly and personally support the stance that it indeed was genocide. If their opinion is of course of importance to you, which I think a bit it is, considered a good chance of around 40 heads of states being a bit more knowledgeable than us both.
You are also mixing up the different periods of Ottoman rule. By 1915 it was all but over, and I understand the simple historical experience when Empires ruled. I do not HATE the Ottoman rule, I just like to uncover the truth. And now you are saying something like "Not even a million lived there". There, where? They lived around there alright.
Also Ottoman Empire is not modern Turkey. History forgives. The facts are mostly on my side though.
Well, the wish to boot fast is actually under attack from many corners. First off, if you want to boot fast you have to scrap the proprietary BIOSes, or over-intrusive BIOSes altogether. BIOS as we still have it now, is a remnant of the past. Granted the first instruction the CPU does when machine is hot-powered comes from the BIOS-owned storage. And 'owned' is the keyword here. We are still dealing with closed-source BIOSes, and they also do like to take their time. Most of the services they provide are today irrelevant and rudimentary. So part of the solution is to minimize time spent in BIOS bootstrapping. Apple does it partially with its EFI-like OpenFirmware, and Intel has sort of caught on with their EFI too. So it is true that Apple people are living in the future. We only have BIOS because apparently someone needs it. But I am sure these folks are nowhere near the mass of people who just simply cannot understand why we still have those ancient cemented irreplaceable proprietary blobs of code on modern motherboards. Granted motherboard makers tweak their own little quirks like buggy ACPI tables etc in their blackbox-like BIOS ROMs, but then this is yet another reason to get rid of this culture. I may be idealistic, but Linux caught on, and I think BIOSes will go away soon too.
Another thing I see is research into compilation techniques and software analysis. This has a bit to do with the usual cry for "do it in assembler if you need speed". What this essentially means is that manual human labour in assembly language deems faster leaner code than that same assembler code spit out by a C compiler for instance. The truth is, the compilers are still introducing runtime overhead, which ideally they should not, especially considering that C was designed to translate into RISC/CISC fairly strictly, i.e. a sort of zero-overhead principle compared to manual assembler skills. So the solution is to make more complex compilers which will deal with overhead more efficiently. This will compensate for over-intrusive C programmers that like to abstract their software to the point where their C programs look like a mutated object oriented C++ template mess, painted with macros. I have seen it, and it does look ugly, no wonder the finite-state-machine compiler has no chance whatsoever to claim zero-overhead then.
A bit related to the above is a technique which will take advantage over parallel processes in hardware. Someone here claimed that Asus EEE starts much faster much thanks to its solid state drives, which do not have to spin up. This is simply incorrect as a reason. First, a modern harddrive spins up in a second on average, which is hardly a big deal compared to the overall boot time. Second, it is simply the inability and inflexibility of a bootstrap routine to account for this spinning-up time and do something useful while the disk spins up. This spinning-up hardly blocks the CPU, or other peripherals. So in essence, we are again to blame only ourselves as programmers who are unable to parallelize the bootstrapping efficiently. Incidentally since an Intel x86 CPU is super-scalar and benefits greatly from it, there is no reason we cannot make compilers that emit superscalar software - software that also does out-of-order execution of independent code paths in parallel.
We are just lazy. All we want is to sleep, fuck and eat. The rest comes after. Faster boot up time of our computers is not very important, it is just a small nerdish annoyance:-) There are critical annoyances like bad expensive closed-source software, and then there are the "slow boot" annoyances.
Turks have had the genocide involving one million executed Armenians on their collective conscience since 1915. An act they refuse to acknowledge, despite numerous and thorough investigations by Eastern and Western parties and governments, dug up massgraves and witness accounts. In fact in both U.S.A. and France, publicly refusing the Armenian genocide is an offense punishable by law.
Also, it can be hardly said about Turkey that they do not attack "anyone with another religion" since their Ottoman empire has ravaged Christian Europe several times and gave Europeans, particularly the Greeks, a very bad time for a good while.
Have you been developing Web content yourself? It was a goddamn pain in the ass to be working overtime to acccomodate for the quirks of "the leader" and simultaneously cater for standards. The worst part was not getting payed for the overtime, because the customer was (is?) completely oblivious to the fact that there are millions of people out there who did not use IE even at that time. Even now situation is marginally better when it comes to customer awareness. So it is not about user only, but developers who hate their job, because instead of being truly productive and get their insight from standards documentation they have to dig like rats into internals of a particular technology that noone but vendor knows much about, and dig they do. You missed the "good" days when you had to read a 10 page blog post of a guy who discovered how to make a three column layout work in Internet Explorer 6. That was like, web development on acid, man.
Opera does not endorse "its own" standard, but the ones outlined by W3C. HÃ¥kon Lie, the Opera guy, has been about standards even before he did Opera.
The linked content mentions that this new language is "part of Microsofts new Oslo development strategy...". I guess Microsoft is up to its typical chameleon practices, of course it is absolutely coincidental and natural that after most of Norways relevant figures boicotted ISOs OOXML standard approval decision process, after numerous investigations were launched to bring up irregularities and peculiarities related to the whole voting and all, yes, it is natural that Microsoft decided to host its Tech.NET and Dev.NET (or whatever it is called) in Oslo. Doesn't take a wizard to figure out what is where and why. They feel now they have to undo all the damage they do by walking over dead bodies everywhere.
There is nothing special about Earth. It is the typical observer mistake, when things look different in one way or another from where you are observing.
People around me may be a bit dumb. The observations point to the fact.
No, the developer will not, and usually does not, separate the UI from the application. Neither on the code level nor the level end-user is able to access. You are plainly wrong. A have peeked at a whole lot of lines of code, and much too often developers assume that the functionality their software hides will forever be tied up to the puny widgets they, in their "infinite wisdom" cooked up to access that functionality. Very few products bare the signs that the developer wished to explicitly separate the UI logic from the function logic. Also the run-time is usually too rigid for the user to change anything of UI relevance. And the "target audience" is a rough approximation which has little reality value, since it is proven again and again that users are different. Now tell me again, what you were saying?
Also, the developer can write an UI, as much as a painter can build a house, all if that is what the boss wants. Unless that developer understands that this is not the U.S. Army with an absolute non-possibility of disobeying orders, but rather a software company where people combine their talent to product a good product. I am sorry if you feel a pawn in a big game, and are unable to give a hint to your boss that he most probably has as much (zero) competence in UI design as you yourself. You are afraid you will get fired, because you told him something that is closer to the truth than he wishes for? I understand the fear, but a good boss will heed to a good advice nevertheless. If you are good, change a company. Everyone has a choice. A good developer is maybe not proficient in UI design, but he would know what he can do and what he cannot do, as well as what his contract says he is supposed to do. You are high up in the clouds of confusion here, I am afraid.
I am sorry to say this, but depending on what kind of people that tell you how the UI must look, and I am assuming your boss here, I hope your products never reach me. I am happy they pay your bills though. But I do not regard your boss as an authority in the matters of UI design, even if you "do".
If you are going to design and implement software components that have any UI in them, please FOR THE LOVE OF DOG do not assume yourself to be a competent GUI designer and expert, just because you know how to spell out language logic into your IDE or WYSIWYG editor. Even if it has a GUI editor, leave it alone and abstract your non-GUI logic so that you can connect it to a GUI later when someone competent in the area finishes one for you.
Awful GUIs as a result of mismanaging priorities and areas of competence are all around us, and I am sure you yourself pondered over few bad examples. Now is your chance to understand the issue and not make the same mistake again.
I presume of course that your are a software programmer, not both (which few people are). You are not your target audience, so if you think an OK button should be to the left, it does not make you an authority in the matter.
When it comes to the rest, most is already said. Observe, be careful in the beginning, design as much but not more than you can in advance, minimize the code writing phase (it will spare you your arms and brain). Do not overcomplicate neither the software, nor the tools you will use to create the product, tools like IDE, compiler, UML editor if any, etc. Do not overuse the abundance of choice you as a software developer have. The most useful software is very simple in the sense that it achieves its goal exactly, no less, no more. You will be thanked for that more than you will know. Read books, as much technical as wisdom-and-guidance sort. But reserve an opinion, it is what makes you an unique programmer, not just a typewriter monkey. Be skeptical meeting the type of programmers that try to convince you about some definite programming practices they sincerely think are best. Heed to their wisdom of experience, but reserve an opinion. Value practical code over theoretical approach, because it is the real products we use, not theories. But do not reinvent the wheel, most theories have been implemented in practice, and it is what makes your life easier.
Remember, the most probable goal of your company is to make money, so that you can get your salary and your boss may buy himself a new wristwatch for 2 grand and pay ails to his ex-wife. Combined with the fact that most folks that comprise the bulk of an IT company would not know half of what you will know about IT internals, they will ignorantly still push their own ignorant agenda when it comes to the style of product. It is your job to provide them with the necessary insight so that product is quality, not just a seller. Adobe Photoshop may sell well, but it is in absolute sense a mediocre product.
Maybe if all that idle rigid silicon could be programmed to do other tasks than rendering shaded polygons on screen in a very limited rigid way, it could almost be justified. It has nothing to do with "justifying 300$ or more for than a single PC component". You don't think of a machine that way, but rather what level of functionality you need to have. Still, noone in their right mind but hardcore gamers shells out more than 300$ for a video card. It's the most useless brick you would ever cram in your computer case. It's essentially a brick. When it starts to let itself be programmed for generic logic, then perhaps the price will be justified. Until then, it is just an expensive toy. Funny thing is, even the very job it is supposed to do, especially considering bold claims by manufacturers, is done often by the CPU. Like 3d artists still render their hi-fi shots with the CPU. The GPU is only used for previews. Pity.
Slashdot Mirror
ON WHAT HARDWARE? That number is meaningless unless we know the specifications.
Next time when writing English sentences, try to put verbs before their adverbs. Especially in light of your attempt at lecturing others on English linguistics. My single misspelling was intentional by the way. Now, here is a task for your cheap time - try to find it!
Well, good engineers use interfaces and publish them for exactly the purpose of interoperation. Google and Mozilla on the other hand may have other things in their head.
F*ck Chrome, Picasa, Google Ads, Google Docs, GMail, Google Analitics, Google Earth, Google Maps, Google Moon, Google Mars, Google This and Google That. And fuck Google. That thing is like seeing a street sign with boobies painted on it on every corner - too nice to ignore, too commonplace to react. Partition that house of happy nerds already, and give each something real to do. Taking over the world by injecting "healthy competition" into every conceivable attractive market niche may be profitable and "beneficial" but honestly, are we not tired of this awful hideous illconceived word - "Google."? I do not need to be awaken to the wonderful choice of even more web browsers, because some nerd up there believes they are doing the world a service. Hey Google, want to do something really useful? Download the Firefox source and start working...
Nope. I dont even know that The Onion is. Was. I get the idea it was a joke then?
It is not 'ahead of the curve' unless the end of that curve is in a dumpster, the one where all moronic apple gadgets end up. Not everyone likes Apple style, and even fewer can be led to believe one can ever be as fast a typist using a giant wheel. At least because of the ergonomic factors, the travel distance after all is greater with one giant wheel. I type on my keyboard at about 65 words per minute IN ANY LANGUAGE, without using a T9 type dictionary. I seriously doubt the limitations of a giant wheel will ever let me approach that speed, even after getting accustomed to it fully and using the dictionary like the guy in the video seems to be using.
What Apple should do if they feel like innovating, is to put a touch sensitive LCD display instead of the keyboard so that software may render keyboard keys and what not on that display which people can tap on just as they type and tap a regular keyboard. A goddamn wheel may have worked for an iPod which had to have effective song list scrolling but for a general purpose laptop machine it is a third wheel literally.
Data density is just too low for the kind of volume he is dealing with ;-)
True, but Linux is a poster child, sort of. It rides on qualities of its own, which justify the "17 years and still lacks features" line:
1) Decentralized development
2) Developers understand that their code is a public property and have to find other ways to profit from their work, which is not always easy
3) Serious hardware vendor support became fashion just a couple of years ago soonest
4) It had to compete with the status-quo software market for most of its lifetime
So - hobbyists scattered all over the planet working on code together, with only 15% working in the office traditional way (Red Hat, Debian etc), not all getting payed for the same kind of work, having to reverse-engineer stuff third of their time on average trying to convince the world they have a genuine offer - pretty much a mess and having enough hands to keep tidying it up is not so bad an achievement still. It could be better indeed, you are right, but in that case I mean it should not have been a POSIX/UNIX style at all. I wont go into that now...
What would be the procedure like then when needing to install an operating system on a pristine primary and single hard drive?
Say you do not have access to CD/DVD reading hardware nor the media itself. Most of Linux distribution installations, not to mention Windows, are prepared for automatic bootstrapping (El-Torito) install.
How do you do it, and is it convenient? I am just curious. Even if you could alter the OS installing procedure to your liking.
As far as I am concerned, the issue outlined above is a good reason SO FAR to keep removable media around. When we have more flexible installers (yes, many Linux distributions HAVE far more flexible installers than necessary, but still) then maybe we can scrap CD/DVD media in favour of hot-swapped terabyte harddrives (already very well doable today).
1. Reuse if a maintained, actively developed component exists that provides the functionality, especially if the component is advertised for reuse - i.e. a library made for linking.
2. Reuse if you know you know less about implementing needed functionality than you plan to spend time and energy learning. Some things do need time to learn, and the mere programming skills do not help much if you are expected to dig into documentation of different standards and hardware specifications.
3. Reuse generally when any solution already exists, because wrapping up a bad component through a flexible interface is better than tightly coupling self-developed component. Later you may replace the mediocre component with a better candidate, but will retain the interface, so minimal changes will be required to your product.
4. Reuse generally, because through wrapping up a piece of foreign code, will give you the benefit of unit-testing, since the chance of even a mediocre foreign component working better than your first attempt to replicate its functionality is fairly high. This gives you two advantages, the one described at 3. and the benefit of said unit-testing.
5. Rewrite if you plan to after-maintain the developed component you otherwise would reuse from somewhere else, especially if you will consider giving it its own life as a standalone generic solution.
6. Runtime linking is teoretically a better idea, however practically, almost every time the version of the linked library changes, the whole product suffers due to degrees of incompatibility with the said library, however promised its version compatibility. This unfortunately happens much to often, one of the reasons many seasoned developers prefer to embed code at compilation time, thus eliminating the runtime incompatibility problem. They make up for it by frequently (or infrequently, pick yours) recompiling and publishing their host product with the updated library version re-compiled into it.
I think 'harder' is improper word here. When a compiler is ready, porting it to another architecture may only make it marginally slower at first, due to challenges in achieving optimization when emitting code for that platform. The compiler logic however is very well shared across platforms, be it flavors of RISC or CISC. A proper word IMO would instead be simply 'more work'. Whether the compiler emits a "jmp" or "mov" or "cmp" instructions, or RISC primitives, it is equally doable. The challenges with developing compilers, JIT included, lie on a higher abstraction level, with finite-state-machines, dependency tree building and accounting for a platforms inability to do certain things that are part of the language (such as structure granularity in C, and how the programs well-behavior may depend on it).
Nice sig btw.
Don't you read, man? There are tons of fine details, credible and verifiable sources that lend far more credibility to the fact that it happened, than your puny excuse for a history lesson you shared with us, however inspiring it may be. Pretty much all evidence points to the fact that a genocide did happen, exact numbers and places varying. Armenian nation counted for around two million by 1915 already, scattered across within the borders of the Ottoman Empire, all the way to the west. There are countless more details, but you seem to be reading all the wrong articles. And it is not only Armenian diaspora doing the research, also Russian, French and English researchers doing their job. Even now the facts continue to unravel, and it sucks more and more to deny it. We can dispute what, were and how much happened, but hundreds of thousands of hungry Armenians forced to march deliberately without food and water into Syrian deserts did die.
Extreme or no extreme, Hrant Dink or no Hrant Dink. Peace.
I am wrong indeed on this. Noted.
1. No I am not joking.
2. I did not say a million Armenians lived in Ottoman Empire. But they did, because the Armenia itself, their historical land, was part of the Ottoman Empire which at the time engaged Russia right on their (Armenian) land when everybody went trigger-happy as part of WW-I. The point is a million has perished around there.
3. It is very good they live in peace. It is always good. They just played a soccer game, which did not end up in killings like some thought. What is your point here, if you have any?
4. Don't tell me what to read, I do read enough history and more on controversial subjects like this, it appears you are short tempered though.
5.By your logic, if Hitler wished to do holocaust then a lot of nations in Europe would have disappeared by now. They have not indeed, but not because Hitler did not succeed in killing millions others. More could have died, but there is such thing known as opposing force. You have just written a meaningless paragraph, which is even less meaningful as an argument.
6. Many oppressing regimes allowed a good degree of sovereignity for the members of their empires. This did not stop the rulers from brutality on a case by case basis, and Armenians must have really scratched the Ottoman Empires itch.
And also, the fact that over a million Armenians have disappered from the face of the Earth is acknowleged as a fact even more so than the fact that it was a genocide. Additionally, most of U.S. states explicitly and personally support the stance that it indeed was genocide. If their opinion is of course of importance to you, which I think a bit it is, considered a good chance of around 40 heads of states being a bit more knowledgeable than us both.
You are also mixing up the different periods of Ottoman rule. By 1915 it was all but over, and I understand the simple historical experience when Empires ruled. I do not HATE the Ottoman rule, I just like to uncover the truth. And now you are saying something like "Not even a million lived there". There, where? They lived around there alright.
Also Ottoman Empire is not modern Turkey. History forgives. The facts are mostly on my side though.
Are you Turk or what?
Well, the wish to boot fast is actually under attack from many corners. First off, if you want to boot fast you have to scrap the proprietary BIOSes, or over-intrusive BIOSes altogether. BIOS as we still have it now, is a remnant of the past. Granted the first instruction the CPU does when machine is hot-powered comes from the BIOS-owned storage. And 'owned' is the keyword here. We are still dealing with closed-source BIOSes, and they also do like to take their time.
Most of the services they provide are today irrelevant and rudimentary. So part of the solution is to minimize time spent in BIOS bootstrapping. Apple does it partially with its EFI-like OpenFirmware, and Intel has sort of caught on with their EFI too. So it is true that Apple people are living in the future. We only have BIOS because apparently someone needs it. But I am sure these folks are nowhere near the mass of people who just simply cannot understand why we still have those ancient cemented irreplaceable proprietary blobs of code on modern motherboards. Granted motherboard makers tweak their own little quirks like buggy ACPI tables etc in their blackbox-like BIOS ROMs, but then this is yet another reason to get rid of this culture. I may be idealistic, but Linux caught on, and I think BIOSes will go away soon too.
Another thing I see is research into compilation techniques and software analysis. This has a bit to do with the usual cry for "do it in assembler if you need speed". What this essentially means is that manual human labour in assembly language deems faster leaner code than that same assembler code spit out by a C compiler for instance. The truth is, the compilers are still introducing runtime overhead, which ideally they should not, especially considering that C was designed to translate into RISC/CISC fairly strictly, i.e. a sort of zero-overhead principle compared to manual assembler skills. So the solution is to make more complex compilers which will deal with overhead more efficiently. This will compensate for over-intrusive C programmers that like to abstract their software to the point where their C programs look like a mutated object oriented C++ template mess, painted with macros. I have seen it, and it does look ugly, no wonder the finite-state-machine compiler has no chance whatsoever to claim zero-overhead then.
A bit related to the above is a technique which will take advantage over parallel processes in hardware. Someone here claimed that Asus EEE starts much faster much thanks to its solid state drives, which do not have to spin up. This is simply incorrect as a reason. First, a modern harddrive spins up in a second on average, which is hardly a big deal compared to the overall boot time. Second, it is simply the inability and inflexibility of a bootstrap routine to account for this spinning-up time and do something useful while the disk spins up. This spinning-up hardly blocks the CPU, or other peripherals. So in essence, we are again to blame only ourselves as programmers who are unable to parallelize the bootstrapping efficiently. Incidentally since an Intel x86 CPU is super-scalar and benefits greatly from it, there is no reason we cannot make compilers that emit superscalar software - software that also does out-of-order execution of independent code paths in parallel.
We are just lazy. All we want is to sleep, fuck and eat. The rest comes after. Faster boot up time of our computers is not very important, it is just a small nerdish annoyance :-) There are critical annoyances like bad expensive closed-source software, and then there are the "slow boot" annoyances.
Turks have had the genocide involving one million executed Armenians on their collective conscience since 1915. An act they refuse to acknowledge, despite numerous and thorough investigations by Eastern and Western parties and governments, dug up massgraves and witness accounts. In fact in both U.S.A. and France, publicly refusing the Armenian genocide is an offense punishable by law.
Also, it can be hardly said about Turkey that they do not attack "anyone with another religion" since their Ottoman empire has ravaged Christian Europe several times and gave Europeans, particularly the Greeks, a very bad time for a good while.
Who said it is?
Have you been developing Web content yourself? It was a goddamn pain in the ass to be working overtime to acccomodate for the quirks of "the leader" and simultaneously cater for standards. The worst part was not getting payed for the overtime, because the customer was (is?) completely oblivious to the fact that there are millions of people out there who did not use IE even at that time. Even now situation is marginally better when it comes to customer awareness. So it is not about user only, but developers who hate their job, because instead of being truly productive and get their insight from standards documentation they have to dig like rats into internals of a particular technology that noone but vendor knows much about, and dig they do. You missed the "good" days when you had to read a 10 page blog post of a guy who discovered how to make a three column layout work in Internet Explorer 6. That was like, web development on acid, man.
Opera does not endorse "its own" standard, but the ones outlined by W3C. HÃ¥kon Lie, the Opera guy, has been about standards even before he did Opera.
Now I hope thats some food for thought for you ;-)
The linked content mentions that this new language is "part of Microsofts new Oslo development strategy...". I guess Microsoft is up to its typical chameleon practices, of course it is absolutely coincidental and natural that after most of Norways relevant figures boicotted ISOs OOXML standard approval decision process, after numerous investigations were launched to bring up irregularities and peculiarities related to the whole voting and all, yes, it is natural that Microsoft decided to host its Tech.NET and Dev.NET (or whatever it is called) in Oslo. Doesn't take a wizard to figure out what is where and why. They feel now they have to undo all the damage they do by walking over dead bodies everywhere.
Exactly how will this confuse the bots?
I do not see a good reason why a third-party (as opposed to using ISP services, already payed for) email service should not be payed for?
There is nothing special about Earth. It is the typical observer mistake, when things look different in one way or another from where you are observing.
People around me may be a bit dumb. The observations point to the fact.
No, the developer will not, and usually does not, separate the UI from the application. Neither on the code level nor the level end-user is able to access. You are plainly wrong. A have peeked at a whole lot of lines of code, and much too often developers assume that the functionality their software hides will forever be tied up to the puny widgets they, in their "infinite wisdom" cooked up to access that functionality. Very few products bare the signs that the developer wished to explicitly separate the UI logic from the function logic. Also the run-time is usually too rigid for the user to change anything of UI relevance. And the "target audience" is a rough approximation which has little reality value, since it is proven again and again that users are different. Now tell me again, what you were saying?
Also, the developer can write an UI, as much as a painter can build a house, all if that is what the boss wants. Unless that developer understands that this is not the U.S. Army with an absolute non-possibility of disobeying orders, but rather a software company where people combine their talent to product a good product. I am sorry if you feel a pawn in a big game, and are unable to give a hint to your boss that he most probably has as much (zero) competence in UI design as you yourself. You are afraid you will get fired, because you told him something that is closer to the truth than he wishes for? I understand the fear, but a good boss will heed to a good advice nevertheless. If you are good, change a company. Everyone has a choice. A good developer is maybe not proficient in UI design, but he would know what he can do and what he cannot do, as well as what his contract says he is supposed to do. You are high up in the clouds of confusion here, I am afraid.
I am sorry to say this, but depending on what kind of people that tell you how the UI must look, and I am assuming your boss here, I hope your products never reach me. I am happy they pay your bills though. But I do not regard your boss as an authority in the matters of UI design, even if you "do".
If you are going to design and implement software components that have any UI in them, please FOR THE LOVE OF DOG do not assume yourself to be a competent GUI designer and expert, just because you know how to spell out language logic into your IDE or WYSIWYG editor. Even if it has a GUI editor, leave it alone and abstract your non-GUI logic so that you can connect it to a GUI later when someone competent in the area finishes one for you.
Awful GUIs as a result of mismanaging priorities and areas of competence are all around us, and I am sure you yourself pondered over few bad examples. Now is your chance to understand the issue and not make the same mistake again.
I presume of course that your are a software programmer, not both (which few people are). You are not your target audience, so if you think an OK button should be to the left, it does not make you an authority in the matter.
When it comes to the rest, most is already said. Observe, be careful in the beginning, design as much but not more than you can in advance, minimize the code writing phase (it will spare you your arms and brain). Do not overcomplicate neither the software, nor the tools you will use to create the product, tools like IDE, compiler, UML editor if any, etc. Do not overuse the abundance of choice you as a software developer have. The most useful software is very simple in the sense that it achieves its goal exactly, no less, no more. You will be thanked for that more than you will know. Read books, as much technical as wisdom-and-guidance sort. But reserve an opinion, it is what makes you an unique programmer, not just a typewriter monkey. Be skeptical meeting the type of programmers that try to convince you about some definite programming practices they sincerely think are best. Heed to their wisdom of experience, but reserve an opinion. Value practical code over theoretical approach, because it is the real products we use, not theories. But do not reinvent the wheel, most theories have been implemented in practice, and it is what makes your life easier.
Remember, the most probable goal of your company is to make money, so that you can get your salary and your boss may buy himself a new wristwatch for 2 grand and pay ails to his ex-wife. Combined with the fact that most folks that comprise the bulk of an IT company would not know half of what you will know about IT internals, they will ignorantly still push their own ignorant agenda when it comes to the style of product. It is your job to provide them with the necessary insight so that product is quality, not just a seller. Adobe Photoshop may sell well, but it is in absolute sense a mediocre product.
Thanks for reaching this far.
Maybe if all that idle rigid silicon could be programmed to do other tasks than rendering shaded polygons on screen in a very limited rigid way, it could almost be justified. It has nothing to do with "justifying 300$ or more for than a single PC component". You don't think of a machine that way, but rather what level of functionality you need to have. Still, noone in their right mind but hardcore gamers shells out more than 300$ for a video card. It's the most useless brick you would ever cram in your computer case. It's essentially a brick. When it starts to let itself be programmed for generic logic, then perhaps the price will be justified. Until then, it is just an expensive toy. Funny thing is, even the very job it is supposed to do, especially considering bold claims by manufacturers, is done often by the CPU. Like 3d artists still render their hi-fi shots with the CPU. The GPU is only used for previews. Pity.