That's not the job of GCC. That's the job of additional tools that work with the files.
These additional tools still need a parser. The obvious way to make additional tools that parse the source code into a syntax tree exactly the same way as GCC, including GCC's extensions to the languages that it implements, is to use GCC's parser. Do ctags and cscope implement all of GCC's extensions correctly?
The problem is that they don't need to do it the exact same was as GCC. They need to do it based more on the language (C, C++, D, A, B, Java, Modula, etc), and produce something useful for the IDE to provide useful functionality for the user.
GCC and any compiler need to parse and product useful information for the internals.
While not 100% mutually exclusive, they are pretty close to it (probably 80-90% mutually exclusive in the output of the parser). Bloating the compiler to generate the additional output information - which will be very specific to each IDE - makes no sense.
No, he got the point. He was accusing you of being disingenuous because there's a trend of people just like you claiming "we don't know" and therefore "we shouldn't do anything".
My position: We don't know how much human activity is causing it; however, we should still strive to do our best as stewards - therefore, emiting the least pollution, etc.
The one side of the issue (human activity being the cause - something which may take another 10k years to prove) is about something entirely different from the other side (being a good steward of resources).
That said, I won't say that I am in the majority in this respect.
If you care about more than i386, ARM, MIPS, PowerPC then you're a massive minority. If by platform you're talking about OS... clang supports OS X, windows, linux, FreeBSD (actually, any BSD I can think of), and I've made it compile on solaris, so there's really no problem here.
Check the Linux Source Tarball, they support far more than i386, ARM, MIPS, and PowerPC - I count 27 architectures in Linus's current tree.
"Dropping utility over licensing kind of smacks of the thing GNU is accused of when BSD advocacy folks get all snooty about technical superiority."
Like how Linux wont use ZFS because of the CDDL? How's that BTRFS working out for you?;-)
There's a difference. The FreeBSD/OpenBSD folks tend to drop something simply because it is not a BSD license, regardless of any other merit of the product, or how it is integrated. Linus refused ZFS because it was under CDDL because of licensing incompatibilities. It was stated very early on that they would have preferred it under the GPL and if so it probably would have gotten integrated.
So you have the "reject simply because we don't like the license" vs. "reject because we can't use the license" - an Apple vs Oranges comparison.
It's entirely necessary if using the compiler to drive code completion, syntax highlighting and in-edtior display of compiler errors and warnings. All of these are things are highly interactive and users will notice the lag of GCC getting invoked every time they type a character in their editor. GCC's clunky pre-compiled header support really doesn't help matters.
If you're doing it with tight compiler integration then you're doing it wrong.
Of course, as I said earlier, lots of tools have provided this kind of functionality without deep integration of the compiler into the editor, but ultimately to do it properly, you'd still be looking at a great deal of effort to implement the first couple of stages of the compiler pipe-line and get an AST (or equivalent).
What those tools do have nothing to do with the first stages of compilation; and can be achieved a lot simpler than doing a compilation stage.
Right now the shit way works better and gives us much better tools integration. You'll find that MS takes a similar approach with.NET and Roslyn and it leads to great results. There's a difference between "The shit way" and "The way that we tried years ago but were shit at coding it".
MSVS does a number of things, and is often very broken. They build separate database files for the various IDE functionality.
However, I don't think they even do things the way you are suggesting. For instance, there are a number of projects I work on (for work) where the IDE environment is completely broken when it comes to trying to find information about classes, functions, variables, etc - things that intellisense should work just fine on; however, the compiler has no issue with compiling the project. (This is true from VS6 through VS2008; I haven't tried VS2010, but as it is an evolution of VS2008 it will probably be the same).
Now, you are mentioning.Net. They may be emulating the behavior you are thinking they are doing by running it through the compilation process more often to generate the same data. However, I don't think they've fundamentally changed how they do intellisense, etc from how they do it with C++, VB, etc either.
One of the key design objectives of Clang is that it is highly modular, and implemented in such a way that various compilation stages are self-contained, and have clean APIs and data structures. This allows development tools such as IDEs to link directly against the stages of the compilation pipeline then need to implement syntax highlighting, code completion, refactoring tools and so on.
Apple's XCode does precisely this, and licensing and lack of modularity in the GCC source tree would have been major factors in their choice to support Clang and LLVM development.
The traditional way of implementing these functions in IDEs has been to effectively re-implement the front-end of the compiler (often not completely). This is a big deal when developing in C++ against the STL/Boost/TR1 when you find that code completion can't grok template properly.
It's the traditional way because it is not a function of the compiler to do those front-end things. Debuggers offer a part of the functionality when running the code; but they're of limited use. However, if you don't want to have to recompile the code all the time, then you're front end tools (e.g. IDEs) need to be able to understand the syntax, etc using their own tools, storing the data in meaningful manners (e.g. internal databases), etc. None of that is the job of a compiler.
This is something that XCode and Visual Studio (which takes a similar approach) are both capable of doing.
Qt Creator can do that quite well too, and works with VS and G++/GDB.
The only valid way of integrating compiler with custom tools is calling the compiler from them
So what's the valid way of finding what functions exist and what variables belong to what functions? Such functionality is needed for "go to definition of selected symbol" and "search for uses of selected symbol" actions.
That's not the job of GCC. That's the job of additional tools that work with the files. One such tool is grep, others are ctags and cscope; that is by no means an exhaustive list, and one could certainly write their own tools to do so.
In fact, I'd argue it's more a function of the IDE to track that information as it provides editor and knows when things change so it can therefore keep this listing up-to-date instead of having to wait on the compilation to be done (which would have to be done if GCC were used).
Now perhaps the real question you're getting as it how do you manage the linked binary with the source for debugging; but again, that's not the function of GCC; rather it is the function of debuggers such as GDB which also provides extensive hooks for IDEs to be able to manage that.
All-in-all, you can use GCC and GDB under the GPLv3 in this manner and provide the functionality you specify, and deliver non-GPL software implementing it without violating the GPL (v2 or v3).
Sadly, states passing laws about sticking to the right lane unless passing are not helping much.
The reason for that is because people driving slowly in the left lane arguably aren't obstructing traffic, because traffic can still get around them. In Europe, they closed that loophole by making it illegal to pass on the right, and therefore someone driving slowly in the left lane is irrefutably obstructing traffic.
They are still considered to be obstructing traffic in the US; and you can in fact get in trouble in the US for passing on the right. I'm not 100% positive, but I believe some states do have laws about passing on the right.
Some states (e.g. Pennsylvania) have made it illegal to be in the left lane for more than a given distance (1-3 miles) without passing someone. But enforcement is lax, and not very easy.
On the Autobahn, it's perfectly safe to drive the speed limit while others whip around you at tremendous speeds. The reason is because slow moving vehicles stay to the right, and fast moving vehicles always pass on the left. Consistency is good for safety. So the moral of the story is, if you're going slower than the normal speed of traffic, stay in the right lane. In fact, it's the law in some places.
The problem is too many people try to do the speed limit and stick in the left lane for a variety of reasons - smoother road surfaces, they just feel like it, they want to limit traffic speed, etc. Sometimes it is necessary (right lane has too many pot holes); but most of the time it's for illegit reasons.
Sadly, states passing laws about sticking to the right lane unless passing are not helping much.
Once again, as I said, the security model doesn't matter for an end-user if the end-user is not educated about threats. It doesn't matter what the security model is, whether it's software API or physical security measures: uneducated users WILL fuck it up. Education is more valuable than ANY software-based countermeasure.
Any level of education does little good if the basic functionality of the security model is not secure.
You can educate a user about being secure all you like; however, that will not stop a valid piece of software from being broken into by another valid piece of software if the security model allows it - it's still insecure.
For example, in Windows 95 you could query the Win32 API for the coordinates of the mouse. You could then take the coordinates and query the Win32 API for the text at those coordinates. It would then provide you back the text of whatever was underneath the mouse at that time - even hidden passwords. This could be done in as little as 6 lines of VB code. And yes, I used it to retrieve a password we forgot. While it was a valid use of the APIs it was nonetheless a security issue. (Microsoft did later start encrypting the text in some manner if the text box was configured as a password text box; but you can still retrieve the text.)
Similarly, the Win32 API can be used to modify the UI displays of other programs without the authorization by the program that generated the UI display. Again, valid software can modify other valid software by design.
These are just 2 examples within the Win32 API of how it is designed to be insecure. No amount of security training of the end-user would stop them from being insecure.
So while your point that education is important, it is equally important that the APIs and systems be secure as well. Any amount of security in the software will be broken by poorly educated users; and any amount of education of the users will be undermined by insecure software and platforms. This one reason why despite additional training in security of the end users Windows still has problems with malware and viruses.
Want more secure computers? Educate the users about security and threats in the wild. It's an operating system agnostic concept.
You have to first start with a security model that actually works. Microsoft's chosen security model has too many flaws.
Second, you have to have applications that respect the security model and can use APIs that are secure. The Win32 APIs are unsecure by design, so there is no hope there for security. I hope the WinRT APIs (for Win8) are better in that respect, but I doubt it. Once APIs are secure then applications can be secure too.
Failing all that, it is the end-user. But until those are solved, then there is little the end-user can do to make their system secure.
Fun fact: Hotmail and MSN used to lock up your account after N failed attempts in order to prevent an account from being brute-forced. So someone created a script that locks a person of your choice out of their MSN account by bruteforcing it and purposely failing.
I just hope they don't go back to that.
Fun Fact: Everyone else will lock the account and notify you via a separate form of communication so you can unlock it - e.g. an alternate email, a phone text message, etc. You then have to go through that other method to reset your password.
Of course, to Microsoft there is only "1 Microsoft Way" so why would anyone have a second account at another site that they could authenticate against? And if you're HotMail/LiveID login is tied to your desktop, phone, and e-mail - well, there goes using other devices for it too if those devices are running Win8 as they would likely be compromised and unreliable. (Just think, the hacker locks your account, which then locks you out of your phone, so you can't get the text message to reset the password.)
Um, each Java thread runs independently, and in The oracle JVM they're OS threads, so assuming that one wrote 'JavaForKernel' module extensions (and a shared runtime hook), there's no reason why it wouldn't be feasible for Java or a java like language to be used in the kernel. That said, its a horrible horrible idea as a result of performance and memory management overhead and bloat, but it would be a neat idea to be able to debug drivers on the fly instead of performing black rites to get C debuggers working nearly as effectively as Java ones do out of the box.
The issue is not whether you could push Java into Kernel space. I agree that could be done though it would be a horrible idea for performance/etc.
The issue is that Java does not provide the facilities itself for talking to hardware like C/C++ and Assembly do. It's facilities to do so are escapes to C and Assembly in a similar manner to how C++ escapes to C and C/C++ escape to Assembly.
So, you could ulimately write a Kernel in Java is feasible, you'd still need support from C/Assembly to actually make it interact with the hardware.
It's cheaper to fire your Java developers and hire C developers than to replace all the servers in your cloud.
Unfortunately that has been the Java mantra for years. Have a performance issue? Upgrade the hardware.
Interestingly, the mantra broke when Intel/AMD started doing multi-core as the initial multi-cores were each rated at about half the rate of the combined rating (e.g. 2 700MHZ processors to achieve a 1400MHZ combined processor). Java just didn't add up any longer in that sense.
Yes, there are uses for Java, but performance is not one of them. Any time you need performance you need an efficient language without garbage collection. C# suffers the same issue.
You can't write device drivers and such in Java, at least not without escaping to Assembly if not C/C++. Java just lacks the basic functionality and capability to do so, but so does any other VM'd language (e.g. Python, Perl, etc.) - it's the nature of running in a virtual machine, along with the performance penalty for doing so as well.
"Programmers in their 40s have wives, kids, and hobbies, and that means they won't put up with the 50-60 hour week bullshit we can get the 20-year-olds to eat."
There's a flip side to that. In my 20's, I could quit on a whim if the boss pissed me off. Now I have a mortgage and a baby on the way. It's like an incentive to work hard and stick around that the company doesn't even have to pay for.
They pay for it through your benefits if you have benefits through your employer.
I hate that term "best practices", especially when used to describe doing something correctly as it is subjective. what i consider Best may not be what you consider Best. I'd rather know that they followed "effective practices" to do the job, while the action they took might have been inefficient, there might be newer ways to do it, but as long as it is still "effective" it should be acceptable.
"Best Practices" is not something that is 100% subjective. It is set by your peers doing similar things. If you are doing something that doesn't fall in th scope of what is provided, then you may have to write a new "Best Practice" as you forge your way through.
Likewise, if you find a better process, you can document it and why you are deviating from it, and still be within "Best Practices" as it will then help to define a new "Best Practice" - its how they change.
I do agree though that "Best Practices" is often over-used, and many times ill-fitting; but that's usually because they are being incorrectly applied - e.g. when a manager tries to take "Best Practices" from one project and apply them to a completely unrelated project where they don't really apply without adjusting them for the differences in the projects.
Will they include a HAL in Windows RT that allows people/hackers to install it on virtually any ARM architecture? Like... say an HP Touchpad?
WinRT is WinNT just as much as Win8/7/Vista/XP/2k/NT4/NT3.5/NT3 are. As such it will have the full HAL and everything else. It just won't have binary compatibility with the X86/X86-64 lines of Windows, much like WinNT PPC/MIPS/etc. was in the past.
Unlike WinCE, WinRT will probably be built from the same exact code-base as Win8 X86/X86-64; again, just like the WinNT PPC/MIPS/etc that they use to have.
WinCE was a completely separate code-base that was usually provided to embedded developers to port to their own CPU architectures. As such, they could modify it to get better performance out of it, remove what wasn't necessarily, etc. But it also left out the HAL and many other things.
Yes, technology makes it easier to spend money than ever before.
While most here have focused on the items being spent on (e.g. phone, internet, TV, etc.) and technology certainly does add to the bottom line in those respects; there is also some fundamental sides where technology makes it easier too - e.g. debit and credit cards.
Many have tried the little trick of using Cash vs. Debit/Credit cards; and all else being equal find that using Cash (e.g. cold hard currency) saves them 33% over using Debit/Credit cards. Why? It's a psycological thing. When you're physically handling the money, it's harder to fork over so much when you are carrying it around - that is, $5 seems like a lot more when you hand over a $5 USD bill (or 5 Euro) than when you just put it on the card and its a number on paper. So you will tend to conserve more from the psychological aspect alone.
Now factor in other technological factors - e.g. internet, TV, etc - and it affects the apparent standard of living, making it higher than it really ought to be. For me, Internet is required as it is part of my livelihood so I have a higher standard of living than if the Internet didn't exist. (I could probably still do my livelihood, but it would be a bit more difficult.)
The list goes on, and yes, these things can be directly attributable to technology.
Of course, it doesn't help that many today don't understand debt vs assets either - whether economists or not. Anytime someone argues that "debt is a good thing" they are verifiably demonstrating how much they don't understand the nature of debt itself, or the cost of it. That not to say that debt should be avoided at all costs; but that it is not necessarily a good thing.
Don't confuse lack of familiarity with bad design.
I'd grant you that for things that are not very basic. However, a good design would provide for the very basics of the functionality to be easily accessible - enough that new users would be able to use the program regardless of their familiarity with it.
The motors don't have to be in the wheels, they can just be located by each wheel and provide power to it. You just replace the axles or whatever with a pair of motors. You'll still have some kind of linkage to connect each motor to its wheel so that the motors weight isn't unsprung. The advantage of 4 motors would be better stability control and performance.
Electric Locomotives have actually put motors in wheels for a long while. They of course operate on much smother surfaces than cars and don't to worry about unsprung weight. But one of the manufacturers a few years back started a project aimed at putting their motors in car wheels. Their demonstration vehicle was a Mini Cooper I believe.
Locos typically have the motor mounted above, with a belt to the axle still. And yes, from what I understand, nearly all newer locos currently in use are nearly 100% electric in the drive train, even if they use a diesel engine to power the batteries instead of catenary lines - in either case, they vehicle bodies (and thereby the motors) are still on springs to smooth the ride. Don't know when they changed over in that respect, but it is quite amazing.
However, tracks are not exactly very smooth. True, you don't get potholes like you do on the road, but it can still be a very rough ride. (Disclaimer: I work in the railway diagnostics business at the moment. And yes, even high speed track can be very rough.) The roughness just manifests itself in a different way - through warped track among many other things.
You are assuming that EV will simply replace the current engine and fuel tank with an electric engine and battery... This is not what has to happen.
Currently engines are big and heavy so you only have one. You then have to transfer the rotational energy of the engine to the wheels. But Electric motors are very light and tiny. So why not have 4?
Put a small electric engine in each wheel and you eliminate the entire drive train... no more drive train losses and EV's are back up to 90%.
Your 72% efficiency only applies to ICE cars that have been converted to EV's.
They've tried putting the electric engine in the wheels as you say; however, there are still a lot of problems with doing so.
Some of the initial Prius and other hybrids at the time actually had 2 drive trains - once for the electric side and one for the gasoline side - combined in some manner. Really inefficient as you carry double the weight. I think they're now down to one drive train.
But needless to say, it's not likely going to change from present designs for quite a while due to the issues with the 4 rotational motors.
Black Boxes are typically things that scare Slashdot. We don't know how they work, as compared to a documented "white box" solution.
This definition of a "Black Box" is different. It's an event data recorder, meant to be like the orange devices found at airplane crash sites designed to let everybody know the status of the vehicle before it crashed. No big privacy change because most cars already have one, it's just a law change that requires there be standards,. rules, and such for these things in the future.
Honestly any use of BlackBox would scare me. Their equipment is simply overpriced pieces of (#*$*#*@.
Slashdot Mirror
That's not the job of GCC. That's the job of additional tools that work with the files.
These additional tools still need a parser. The obvious way to make additional tools that parse the source code into a syntax tree exactly the same way as GCC, including GCC's extensions to the languages that it implements, is to use GCC's parser. Do ctags and cscope implement all of GCC's extensions correctly?
The problem is that they don't need to do it the exact same was as GCC. They need to do it based more on the language (C, C++, D, A, B, Java, Modula, etc), and produce something useful for the IDE to provide useful functionality for the user.
GCC and any compiler need to parse and product useful information for the internals.
While not 100% mutually exclusive, they are pretty close to it (probably 80-90% mutually exclusive in the output of the parser). Bloating the compiler to generate the additional output information - which will be very specific to each IDE - makes no sense.
No, he got the point. He was accusing you of being disingenuous because there's a trend of people just like you claiming "we don't know" and therefore "we shouldn't do anything".
My position: We don't know how much human activity is causing it; however, we should still strive to do our best as stewards - therefore, emiting the least pollution, etc.
The one side of the issue (human activity being the cause - something which may take another 10k years to prove) is about something entirely different from the other side (being a good steward of resources).
That said, I won't say that I am in the majority in this respect.
If you care about more than i386, ARM, MIPS, PowerPC then you're a massive minority. If by platform you're talking about OS... clang supports OS X, windows, linux, FreeBSD (actually, any BSD I can think of), and I've made it compile on solaris, so there's really no problem here.
Check the Linux Source Tarball, they support far more than i386, ARM, MIPS, and PowerPC - I count 27 architectures in Linus's current tree.
FreeBSD wants 100% freedom, GPL wants 99.9% freedom. Both camps have very good intentions, but an ever so slight philosophical difference.
Both want 100% freedom. Definitions of freedom vary between the two.
"Dropping utility over licensing kind of smacks of the thing GNU is accused of when BSD advocacy folks get all snooty about technical superiority."
Like how Linux wont use ZFS because of the CDDL? How's that BTRFS working out for you? ;-)
There's a difference. The FreeBSD/OpenBSD folks tend to drop something simply because it is not a BSD license, regardless of any other merit of the product, or how it is integrated. Linus refused ZFS because it was under CDDL because of licensing incompatibilities. It was stated very early on that they would have preferred it under the GPL and if so it probably would have gotten integrated.
So you have the "reject simply because we don't like the license" vs. "reject because we can't use the license" - an Apple vs Oranges comparison.
It's entirely necessary if using the compiler to drive code completion, syntax highlighting and in-edtior display of compiler errors and warnings. All of these are things are highly interactive and users will notice the lag of GCC getting invoked every time they type a character in their editor. GCC's clunky pre-compiled header support really doesn't help matters.
If you're doing it with tight compiler integration then you're doing it wrong.
Of course, as I said earlier, lots of tools have provided this kind of functionality without deep integration of the compiler into the editor, but ultimately to do it properly, you'd still be looking at a great deal of effort to implement the first couple of stages of the compiler pipe-line and get an AST (or equivalent).
What those tools do have nothing to do with the first stages of compilation; and can be achieved a lot simpler than doing a compilation stage.
Right now the shit way works better and gives us much better tools integration. You'll find that MS takes a similar approach with .NET and Roslyn and it leads to great results. There's a difference between "The shit way" and "The way that we tried years ago but were shit at coding it".
MSVS does a number of things, and is often very broken. They build separate database files for the various IDE functionality.
.Net. They may be emulating the behavior you are thinking they are doing by running it through the compilation process more often to generate the same data. However, I don't think they've fundamentally changed how they do intellisense, etc from how they do it with C++, VB, etc either.
However, I don't think they even do things the way you are suggesting. For instance, there are a number of projects I work on (for work) where the IDE environment is completely broken when it comes to trying to find information about classes, functions, variables, etc - things that intellisense should work just fine on; however, the compiler has no issue with compiling the project. (This is true from VS6 through VS2008; I haven't tried VS2010, but as it is an evolution of VS2008 it will probably be the same).
Now, you are mentioning
One of the key design objectives of Clang is that it is highly modular, and implemented in such a way that various compilation stages are self-contained, and have clean APIs and data structures. This allows development tools such as IDEs to link directly against the stages of the compilation pipeline then need to implement syntax highlighting, code completion, refactoring tools and so on.
Apple's XCode does precisely this, and licensing and lack of modularity in the GCC source tree would have been major factors in their choice to support Clang and LLVM development.
The traditional way of implementing these functions in IDEs has been to effectively re-implement the front-end of the compiler (often not completely). This is a big deal when developing in C++ against the STL/Boost/TR1 when you find that code completion can't grok template properly.
It's the traditional way because it is not a function of the compiler to do those front-end things. Debuggers offer a part of the functionality when running the code; but they're of limited use. However, if you don't want to have to recompile the code all the time, then you're front end tools (e.g. IDEs) need to be able to understand the syntax, etc using their own tools, storing the data in meaningful manners (e.g. internal databases), etc. None of that is the job of a compiler.
This is something that XCode and Visual Studio (which takes a similar approach) are both capable of doing.
Qt Creator can do that quite well too, and works with VS and G++/GDB.
The only valid way of integrating compiler with custom tools is calling the compiler from them
So what's the valid way of finding what functions exist and what variables belong to what functions? Such functionality is needed for "go to definition of selected symbol" and "search for uses of selected symbol" actions.
That's not the job of GCC. That's the job of additional tools that work with the files. One such tool is grep, others are ctags and cscope; that is by no means an exhaustive list, and one could certainly write their own tools to do so.
In fact, I'd argue it's more a function of the IDE to track that information as it provides editor and knows when things change so it can therefore keep this listing up-to-date instead of having to wait on the compilation to be done (which would have to be done if GCC were used).
Now perhaps the real question you're getting as it how do you manage the linked binary with the source for debugging; but again, that's not the function of GCC; rather it is the function of debuggers such as GDB which also provides extensive hooks for IDEs to be able to manage that.
All-in-all, you can use GCC and GDB under the GPLv3 in this manner and provide the functionality you specify, and deliver non-GPL software implementing it without violating the GPL (v2 or v3).
The reason for that is because people driving slowly in the left lane arguably aren't obstructing traffic, because traffic can still get around them. In Europe, they closed that loophole by making it illegal to pass on the right, and therefore someone driving slowly in the left lane is irrefutably obstructing traffic.
They are still considered to be obstructing traffic in the US; and you can in fact get in trouble in the US for passing on the right. I'm not 100% positive, but I believe some states do have laws about passing on the right.
Some states (e.g. Pennsylvania) have made it illegal to be in the left lane for more than a given distance (1-3 miles) without passing someone. But enforcement is lax, and not very easy.
The problem is too many people try to do the speed limit and stick in the left lane for a variety of reasons - smoother road surfaces, they just feel like it, they want to limit traffic speed, etc. Sometimes it is necessary (right lane has too many pot holes); but most of the time it's for illegit reasons.
Sadly, states passing laws about sticking to the right lane unless passing are not helping much.
Once again, as I said, the security model doesn't matter for an end-user if the end-user is not educated about threats. It doesn't matter what the security model is, whether it's software API or physical security measures: uneducated users WILL fuck it up. Education is more valuable than ANY software-based countermeasure.
Any level of education does little good if the basic functionality of the security model is not secure.
You can educate a user about being secure all you like; however, that will not stop a valid piece of software from being broken into by another valid piece of software if the security model allows it - it's still insecure.
For example, in Windows 95 you could query the Win32 API for the coordinates of the mouse. You could then take the coordinates and query the Win32 API for the text at those coordinates. It would then provide you back the text of whatever was underneath the mouse at that time - even hidden passwords. This could be done in as little as 6 lines of VB code. And yes, I used it to retrieve a password we forgot. While it was a valid use of the APIs it was nonetheless a security issue. (Microsoft did later start encrypting the text in some manner if the text box was configured as a password text box; but you can still retrieve the text.)
Similarly, the Win32 API can be used to modify the UI displays of other programs without the authorization by the program that generated the UI display. Again, valid software can modify other valid software by design.
These are just 2 examples within the Win32 API of how it is designed to be insecure. No amount of security training of the end-user would stop them from being insecure.
So while your point that education is important, it is equally important that the APIs and systems be secure as well. Any amount of security in the software will be broken by poorly educated users; and any amount of education of the users will be undermined by insecure software and platforms. This one reason why despite additional training in security of the end users Windows still has problems with malware and viruses.
In other words, both are equally important.
Want more secure computers? Educate the users about security and threats in the wild. It's an operating system agnostic concept.
You have to first start with a security model that actually works. Microsoft's chosen security model has too many flaws.
Second, you have to have applications that respect the security model and can use APIs that are secure. The Win32 APIs are unsecure by design, so there is no hope there for security. I hope the WinRT APIs (for Win8) are better in that respect, but I doubt it. Once APIs are secure then applications can be secure too.
Failing all that, it is the end-user. But until those are solved, then there is little the end-user can do to make their system secure.
Fun fact: Hotmail and MSN used to lock up your account after N failed attempts in order to prevent an account from being brute-forced. So someone created a script that locks a person of your choice out of their MSN account by bruteforcing it and purposely failing.
I just hope they don't go back to that.
Fun Fact: Everyone else will lock the account and notify you via a separate form of communication so you can unlock it - e.g. an alternate email, a phone text message, etc. You then have to go through that other method to reset your password.
Of course, to Microsoft there is only "1 Microsoft Way" so why would anyone have a second account at another site that they could authenticate against? And if you're HotMail/LiveID login is tied to your desktop, phone, and e-mail - well, there goes using other devices for it too if those devices are running Win8 as they would likely be compromised and unreliable. (Just think, the hacker locks your account, which then locks you out of your phone, so you can't get the text message to reset the password.)
Um, each Java thread runs independently, and in The oracle JVM they're OS threads, so assuming that one wrote 'JavaForKernel' module extensions (and a shared runtime hook), there's no reason why it wouldn't be feasible for Java or a java like language to be used in the kernel. That said, its a horrible horrible idea as a result of performance and memory management overhead and bloat, but it would be a neat idea to be able to debug drivers on the fly instead of performing black rites to get C debuggers working nearly as effectively as Java ones do out of the box.
The issue is not whether you could push Java into Kernel space. I agree that could be done though it would be a horrible idea for performance/etc.
The issue is that Java does not provide the facilities itself for talking to hardware like C/C++ and Assembly do. It's facilities to do so are escapes to C and Assembly in a similar manner to how C++ escapes to C and C/C++ escape to Assembly.
So, you could ulimately write a Kernel in Java is feasible, you'd still need support from C/Assembly to actually make it interact with the hardware.
It's cheaper to fire your Java developers and hire C developers than to replace all the servers in your cloud.
Unfortunately that has been the Java mantra for years. Have a performance issue? Upgrade the hardware.
Interestingly, the mantra broke when Intel/AMD started doing multi-core as the initial multi-cores were each rated at about half the rate of the combined rating (e.g. 2 700MHZ processors to achieve a 1400MHZ combined processor). Java just didn't add up any longer in that sense.
Yes, there are uses for Java, but performance is not one of them. Any time you need performance you need an efficient language without garbage collection. C# suffers the same issue.
What are you going to write the Java VM in?
You can't write device drivers and such in Java, at least not without escaping to Assembly if not C/C++. Java just lacks the basic functionality and capability to do so, but so does any other VM'd language (e.g. Python, Perl, etc.) - it's the nature of running in a virtual machine, along with the performance penalty for doing so as well.
I think what they're really saying here is:
"Programmers in their 40s have wives, kids, and hobbies, and that means they won't put up with the 50-60 hour week bullshit we can get the 20-year-olds to eat."
There's a flip side to that. In my 20's, I could quit on a whim if the boss pissed me off. Now I have a mortgage and a baby on the way. It's like an incentive to work hard and stick around that the company doesn't even have to pay for.
They pay for it through your benefits if you have benefits through your employer.
follow best practices
I hate that term "best practices", especially when used to describe doing something correctly as it is subjective. what i consider Best may not be what you consider Best. I'd rather know that they followed "effective practices" to do the job, while the action they took might have been inefficient, there might be newer ways to do it, but as long as it is still "effective" it should be acceptable.
"Best Practices" is not something that is 100% subjective. It is set by your peers doing similar things. If you are doing something that doesn't fall in th scope of what is provided, then you may have to write a new "Best Practice" as you forge your way through.
Likewise, if you find a better process, you can document it and why you are deviating from it, and still be within "Best Practices" as it will then help to define a new "Best Practice" - its how they change.
I do agree though that "Best Practices" is often over-used, and many times ill-fitting; but that's usually because they are being incorrectly applied - e.g. when a manager tries to take "Best Practices" from one project and apply them to a completely unrelated project where they don't really apply without adjusting them for the differences in the projects.
Will they include a HAL in Windows RT that allows people/hackers to install it on virtually any ARM architecture? Like... say an HP Touchpad?
WinRT is WinNT just as much as Win8/7/Vista/XP/2k/NT4/NT3.5/NT3 are. As such it will have the full HAL and everything else. It just won't have binary compatibility with the X86/X86-64 lines of Windows, much like WinNT PPC/MIPS/etc. was in the past.
Unlike WinCE, WinRT will probably be built from the same exact code-base as Win8 X86/X86-64; again, just like the WinNT PPC/MIPS/etc that they use to have.
WinCE was a completely separate code-base that was usually provided to embedded developers to port to their own CPU architectures. As such, they could modify it to get better performance out of it, remove what wasn't necessarily, etc. But it also left out the HAL and many other things.
Yes, technology makes it easier to spend money than ever before.
While most here have focused on the items being spent on (e.g. phone, internet, TV, etc.) and technology certainly does add to the bottom line in those respects; there is also some fundamental sides where technology makes it easier too - e.g. debit and credit cards.
Many have tried the little trick of using Cash vs. Debit/Credit cards; and all else being equal find that using Cash (e.g. cold hard currency) saves them 33% over using Debit/Credit cards. Why? It's a psycological thing. When you're physically handling the money, it's harder to fork over so much when you are carrying it around - that is, $5 seems like a lot more when you hand over a $5 USD bill (or 5 Euro) than when you just put it on the card and its a number on paper. So you will tend to conserve more from the psychological aspect alone.
Now factor in other technological factors - e.g. internet, TV, etc - and it affects the apparent standard of living, making it higher than it really ought to be. For me, Internet is required as it is part of my livelihood so I have a higher standard of living than if the Internet didn't exist. (I could probably still do my livelihood, but it would be a bit more difficult.)
The list goes on, and yes, these things can be directly attributable to technology.
Of course, it doesn't help that many today don't understand debt vs assets either - whether economists or not. Anytime someone argues that "debt is a good thing" they are verifiably demonstrating how much they don't understand the nature of debt itself, or the cost of it. That not to say that debt should be avoided at all costs; but that it is not necessarily a good thing.
Don't confuse lack of familiarity with bad design.
I'd grant you that for things that are not very basic. However, a good design would provide for the very basics of the functionality to be easily accessible - enough that new users would be able to use the program regardless of their familiarity with it.
Anything beyond the basics is a different story.
The motors don't have to be in the wheels, they can just be located by each wheel and provide power to it. You just replace the axles or whatever with a pair of motors. You'll still have some kind of linkage to connect each motor to its wheel so that the motors weight isn't unsprung. The advantage of 4 motors would be better stability control and performance.
Electric Locomotives have actually put motors in wheels for a long while. They of course operate on much smother surfaces than cars and don't to worry about unsprung weight. But one of the manufacturers a few years back started a project aimed at putting their motors in car wheels. Their demonstration vehicle was a Mini Cooper I believe.
Locos typically have the motor mounted above, with a belt to the axle still. And yes, from what I understand, nearly all newer locos currently in use are nearly 100% electric in the drive train, even if they use a diesel engine to power the batteries instead of catenary lines - in either case, they vehicle bodies (and thereby the motors) are still on springs to smooth the ride. Don't know when they changed over in that respect, but it is quite amazing.
However, tracks are not exactly very smooth. True, you don't get potholes like you do on the road, but it can still be a very rough ride. (Disclaimer: I work in the railway diagnostics business at the moment. And yes, even high speed track can be very rough.) The roughness just manifests itself in a different way - through warped track among many other things.
You are assuming that EV will simply replace the current engine and fuel tank with an electric engine and battery... This is not what has to happen.
Currently engines are big and heavy so you only have one. You then have to transfer the rotational energy of the engine to the wheels. But Electric motors are very light and tiny. So why not have 4?
Put a small electric engine in each wheel and you eliminate the entire drive train... no more drive train losses and EV's are back up to 90%.
Your 72% efficiency only applies to ICE cars that have been converted to EV's.
They've tried putting the electric engine in the wheels as you say; however, there are still a lot of problems with doing so.
Some of the initial Prius and other hybrids at the time actually had 2 drive trains - once for the electric side and one for the gasoline side - combined in some manner. Really inefficient as you carry double the weight. I think they're now down to one drive train.
But needless to say, it's not likely going to change from present designs for quite a while due to the issues with the 4 rotational motors.
Black Boxes are typically things that scare Slashdot. We don't know how they work, as compared to a documented "white box" solution.
This definition of a "Black Box" is different. It's an event data recorder, meant to be like the orange devices found at airplane crash sites designed to let everybody know the status of the vehicle before it crashed. No big privacy change because most cars already have one, it's just a law change that requires there be standards,. rules, and such for these things in the future.
Honestly any use of BlackBox would scare me. Their equipment is simply overpriced pieces of (#*$*#*@.