That would be injecting noise on to the power lines, which means either it screws with the rest of the grid, or it's small enough that other devices could swamp it with noise. There's been some interesting work done on hiding signals below the noise floor using frequency hopping, but that's excessively complex.
At low speeds such as would be encountered in a parking lot or congested city street the engine noise is dominant, particularly because the car is doing a lot of accelerating and decelerating. At those speeds I think a modest synthesized engine sound is a very good idea, especially when you consider blind people and even more especially service dogs
My experience is that in car parks, you can hear the tire noise easily. If the only problem is the visually impaired, why not put the synthesized sound above the range of human hearing, so that only guide dogs and assistive devices can detect it?
There is quite a bit of object oriented C code in the wild, that request just shows that the guy had no idea what he was talking about. While there are a lot of nice (and not so nice) things you can get from C++ if object orientation is all you want its overkill.
Amusingly, the kernel is probably one of the better examples of how to do OOP in C - the VFS code is a good example of this. (The file_operations struct is basically a vtable.) So given that they already had a working solution, they wouldn't have gained anything from C++ except additional complexity.
The problem is that it is not a sane choice. This is ENTIRELY based on fear. If all you do is label something as GMO that tells you nothing at all. This does not help you make any kind of informed decision at all.
Was the GMO done to make the plant drought resistance? does it resist cold? was it modified to be less carcinogenic? was it modified to make a certain companies fertilizer more profitable? etc
Just saying something is GMO is worthless.
I agree entirely. That's what using a GMO identifier would enable - the database of what changes they correspond to and when they were approved should be publicly accessible. If you think about it, that's basically the same level of transparency we currently have with various additives.
Look at the EU and their policy on GMO. It is ENTIRELY fear based. They just label something as GMO which is completely useless and people are taught that GMO is bad period. Even research into GMO has almost entirely ended in Europe. It doesn't matter that their own studies show the ones they have tested are safe they continue to be against it not just in the EU but world wide. The EU is a pretty major factor in stopping the usage of golden rice.
What would you propose instead? Given that GMO is relatively new, I think it is important that GMO foods be labelled as such, so that consumers can make an informed choice. Of course, some consumers are idiots, but that's never been a strong argument against depriving the rest of us.
I'm not an expert on the topic, but it seems to me that since there is already infrastructure in place for demonstrating that the GMO product in question is safe for human consumption (which no doubt assigns it some kind of UID), simply adding the identifier to the ingredients list should be enough. It conveys to the consumer that not all GMOs are the same, while still informing them. It also makes it easy for people to google a specific strain/variant and see if any one else has reported issues.
All in all I just didn't consider it interesting enough to study even. I'm more interested in a true paradigm shift rather than another iteration of C++ which already is good enough for my taste. So I still have haskell overlay and actually do learn haskell:P
I'll agree with you there - D is the sort of language that tries to copy as many features as possible from other languages, rather than one which tries to do anything truly revolutionary. (I think UFCS is the only novel feature it has, and it's nothing more than a nicety.)
Haskell is definitely a much more interesting language - I spent the entirety of last year working with it and don't feel like I even scratched the surface. There are some applications imperative languages are better for though, so it is nice to see languages like Rust and D providing support for both.
- Huge portions of the standard library are missing attributes like 'pure' and 'nothrow', which directly impacts user code that attempts to include them
Could you explain why adding pure/nothrow is considered a breaking change? I would have thought it only increases the contexts from which the function could be called.
D works quite well with C-based interfaces - you just annotate the function definitions and link against the binaries. (C++ support is a bit more incomplete.) That said, at 264 kLOC, I don't think you're going to be switching to any new languages, except maybe newer revisions of C/C++. New languages are only ever feasible for new systems, rewrites, or loosely coupled modules of existing systems. Anything else just causes more headaches than its worth.
Given that DMD, etc. statically link the standard library by default, the resulting executable won't be significantly difficult from one produced by a C compiler. My guess is you either ran into issues with dub, [1] or you dynamically linked something opengl-related and had trouble due to that on the other systems.
[1] Minor rant: why does language popularised in the last decade need their own, language-specific package management? What's wrong with make or cmake?
I've been using the overlay, and while I don't like how they've put everything in/opt, I haven't had any problems with it. The ebuilds for gdc, etc. are properly bootstrapped.
(The separate directories in/opt are apparently the result of the lack of a stable ABI between compilers, or even between different versions of the same compiler. AIUI, C++ has the same problem, but most distros just treat GCC as the official compiler instead of treating them all equally.)
I have two main gripes with it on that front. D has a horrid GC (though no GC provides the latency requirements we need), and though it claims you can do without it, you really can't. At least, not without giving up on much of the language features and almost all of the standard library. When comparing to C++'s ability to use custom allocators with the standard library, D's phobos seems deathly pale.
Not sure if you know this, but the GC was recently / is being rewritten, which should hopefully improve things. There's also the new std.allocator interface.
That said, I don't think anyone can seriously claim D has good non-GC support, and it sounds like you definitely need a non-GC language given your latency requirements. Rust would probably work better, but it has its own quirks.
"D offers compilers for all three platforms (Windows, Mac and Linux) as well as FreeBSD."
Note that two of those compilers use GCC and LLVM as their back-ends. In practice, this means that you can use D on any architecture they support. For example, here's a patch that adds D support to buildroot toolchains.
I do agree that the third-party libraries available are pretty limited though.
Oh, and I also forgot to mention that functions fail silently if you don't check their error codes, compared to languages which use exceptions. Silent failures can be immensely confusing to newbies.
Because even if you're doing simple things, you need to: - manually manage memory (compared to GC'd languages) - manually store the length of buffers/arrays - preallocate arrays for strings, etc. before copying data to them
C is low-level, which makes sense if you want to learn about what the computer is actually doing. But computer architecture is not something that belongs in an introductory computer science course - control structures and basic data structures are far more important, and C just gets in the way of those.
I said C/C++ because they both use same preprocessor. While I'm sure you could do some interesting things with C++ templates, I haven't seen any use of them that goes beyond generics while still being easy to comprehend. This could be due to my own inexperience though.
And this attempt to make a modular phone seems more like a technology demonstration then a product role out. Does anyone think they will try and make a business line out of it? I doubt it.
I think the idea behind Project Ara is the same as the idea behind their Nexus line - they're not interested in being manufacturers, they just want to raise the bar for devices running their software. They'll (hopefully) establish some critical mass, a few other manufacturers will start making parts, and eventually Google won't need to do anything for the system to be self-sustaining, except maybe push for better specs on Ara 2.0...
It's not like you can't add a third party repository with the latest stable (or development) version of Firefox. Besides, even if you're going to download it somewhere else, would it be good if the OS could check that somewhere else for updates instead of each program have its own auto-update daemon run at startup?
Having worked with D a bit, the biggest difference between it and C++ is that D is garbage collected by default. You can disable the GC and use malloc, but this renders the standard library off limits. Apart from that, I would say that D not only has all the features of C++, it has features that C++ doesn't even have yet. e.g. concepts were proposed as an extension to templates for C++11, but still aren't part of the spec. In contrast, D has support for constraining templates similarly using syntax such as:
T square(T x)
if (isIntegral!T) {
return x * x; }
D also has excellent support for functional and meta-programming. e.g. the pure and immutable keywords. While C/C++ requires you to use macros for meta-programming, D lets you use existing D functions to generate the resulting code.
The more interesting question is really if freedom exists when you never make use of it. (Do you actually hack the kernel or fix somebody's proprietary binary-only drivers as a GNU/Linux user?)
You don't need to directly make use of it though; the mere fact that that freedom exists can influence design choices. A good example of this would be how many (common) Linux drivers are based around the actual chip in the device, as opposed to the specific make and model (as is the norm in Windows). Not needing to install drivers for 99% of supported hardware is a pretty nice benefit, and it's the direct result of the kernel (and by extension, those drivers) being GPL.
Freedom, like everything else, exists because it has consequences that we can perceive.
The Series 9 is a POS (or at least it was when I was buying a new laptop a little over a year ago.) The case has a lot of flex and the keyboard terrible tactile response. Regardless of what the specs (and price) are, I don't think you can argue it's a serious contender for the high end.
'cat/proc/filesystems' lists 47 different file systems, which is a superset of those supported by both Windows and OS X.[1] In terms of what you can actually with just one of those, btrfs enables near-instant (~1 second) snapshots of live file systems, which can then be transferred across the network as incremental backups. It also checksums everything stored on the drive so as to eliminate silent corruption. (With the exception of ZFS, pretty much every other FS around is vulnerable to this.)
OS X may (arguably) have some advantages over Linux in terms of usability, but I don't think you can argue that it has a superior feature set. That's the fundamental difference between them - OS X has a few, highly polished features that serve the needs of the average person (who doesn't mind living in an all-Apple ecosystem), while Linux has almost every feature you could think of with a comparatively small amount of polish.[2]
[1] Note that isn't even exhaustive - it only lists those compiled in or with loaded modules. [2] e.g. There are currently 3+ different ways to use a SSD as a cache for a mechanical drive. None of them have been integrated into the installer for a distro.
Who cares about root! My home directory is WAY more important than the system.
Which means you should have backups that are not writeable by your account, and the easiest way of doing so is having cron create a tarball of/home as root. Alternatively, if you're using btrfs snapshots work great for this.
Slashdot Mirror
What's wrong with UUCP?
That would be injecting noise on to the power lines, which means either it screws with the rest of the grid, or it's small enough that other devices could swamp it with noise. There's been some interesting work done on hiding signals below the noise floor using frequency hopping, but that's excessively complex.
At low speeds such as would be encountered in a parking lot or congested city street the engine noise is dominant, particularly because the car is doing a lot of accelerating and decelerating. At those speeds I think a modest synthesized engine sound is a very good idea, especially when you consider blind people and even more especially service dogs
My experience is that in car parks, you can hear the tire noise easily. If the only problem is the visually impaired, why not put the synthesized sound above the range of human hearing, so that only guide dogs and assistive devices can detect it?
There is quite a bit of object oriented C code in the wild, that request just shows that the guy had no idea what he was talking about. While there are a lot of nice (and not so nice) things you can get from C++ if object orientation is all you want its overkill.
Amusingly, the kernel is probably one of the better examples of how to do OOP in C - the VFS code is a good example of this. (The file_operations struct is basically a vtable.) So given that they already had a working solution, they wouldn't have gained anything from C++ except additional complexity.
The problem is that it is not a sane choice. This is ENTIRELY based on fear. If all you do is label something as GMO that tells you nothing at all. This does not help you make any kind of informed decision at all.
Was the GMO done to make the plant drought resistance? does it resist cold? was it modified to be less carcinogenic? was it modified to make a certain companies fertilizer more profitable? etc
Just saying something is GMO is worthless.
I agree entirely. That's what using a GMO identifier would enable - the database of what changes they correspond to and when they were approved should be publicly accessible. If you think about it, that's basically the same level of transparency we currently have with various additives.
Look at the EU and their policy on GMO. It is ENTIRELY fear based. They just label something as GMO which is completely useless and people are taught that GMO is bad period. Even research into GMO has almost entirely ended in Europe. It doesn't matter that their own studies show the ones they have tested are safe they continue to be against it not just in the EU but world wide. The EU is a pretty major factor in stopping the usage of golden rice.
What would you propose instead? Given that GMO is relatively new, I think it is important that GMO foods be labelled as such, so that consumers can make an informed choice. Of course, some consumers are idiots, but that's never been a strong argument against depriving the rest of us.
I'm not an expert on the topic, but it seems to me that since there is already infrastructure in place for demonstrating that the GMO product in question is safe for human consumption (which no doubt assigns it some kind of UID), simply adding the identifier to the ingredients list should be enough. It conveys to the consumer that not all GMOs are the same, while still informing them. It also makes it easy for people to google a specific strain/variant and see if any one else has reported issues.
All in all I just didn't consider it interesting enough to study even. I'm more interested in a true paradigm shift rather than another iteration of C++ which already is good enough for my taste. So I still have haskell overlay and actually do learn haskell :P
I'll agree with you there - D is the sort of language that tries to copy as many features as possible from other languages, rather than one which tries to do anything truly revolutionary. (I think UFCS is the only novel feature it has, and it's nothing more than a nicety.)
Haskell is definitely a much more interesting language - I spent the entirety of last year working with it and don't feel like I even scratched the surface. There are some applications imperative languages are better for though, so it is nice to see languages like Rust and D providing support for both.
- Huge portions of the standard library are missing attributes like 'pure' and 'nothrow', which directly impacts user code that attempts to include them
Could you explain why adding pure/nothrow is considered a breaking change? I would have thought it only increases the contexts from which the function could be called.
D works quite well with C-based interfaces - you just annotate the function definitions and link against the binaries. (C++ support is a bit more incomplete.)
That said, at 264 kLOC, I don't think you're going to be switching to any new languages, except maybe newer revisions of C/C++.
New languages are only ever feasible for new systems, rewrites, or loosely coupled modules of existing systems. Anything else just causes more headaches than its worth.
Given that DMD, etc. statically link the standard library by default, the resulting executable won't be significantly difficult from one produced by a C compiler. My guess is you either ran into issues with dub, [1] or you dynamically linked something opengl-related and had trouble due to that on the other systems.
[1] Minor rant: why does language popularised in the last decade need their own, language-specific package management? What's wrong with make or cmake?
I've been using the overlay, and while I don't like how they've put everything in /opt, I haven't had any problems with it. The ebuilds for gdc, etc. are properly bootstrapped.
(The separate directories in /opt are apparently the result of the lack of a stable ABI between compilers, or even between different versions of the same compiler. AIUI, C++ has the same problem, but most distros just treat GCC as the official compiler instead of treating them all equally.)
I have two main gripes with it on that front. D has a horrid GC (though no GC provides the latency requirements we need), and though it claims you can do without it, you really can't. At least, not without giving up on much of the language features and almost all of the standard library. When comparing to C++'s ability to use custom allocators with the standard library, D's phobos seems deathly pale.
Not sure if you know this, but the GC was recently / is being rewritten, which should hopefully improve things. There's also the new std.allocator interface.
That said, I don't think anyone can seriously claim D has good non-GC support, and it sounds like you definitely need a non-GC language given your latency requirements. Rust would probably work better, but it has its own quirks.
"D offers compilers for all three platforms (Windows, Mac and Linux) as well as FreeBSD."
Note that two of those compilers use GCC and LLVM as their back-ends. In practice, this means that you can use D on any architecture they support. For example, here's a patch that adds D support to buildroot toolchains.
I do agree that the third-party libraries available are pretty limited though.
Oh, and I also forgot to mention that functions fail silently if you don't check their error codes, compared to languages which use exceptions. Silent failures can be immensely confusing to newbies.
Because even if you're doing simple things, you need to:
- manually manage memory (compared to GC'd languages)
- manually store the length of buffers/arrays
- preallocate arrays for strings, etc. before copying data to them
C is low-level, which makes sense if you want to learn about what the computer is actually doing. But computer architecture is not something that belongs in an introductory computer science course - control structures and basic data structures are far more important, and C just gets in the way of those.
I said C/C++ because they both use same preprocessor. While I'm sure you could do some interesting things with C++ templates, I haven't seen any use of them that goes beyond generics while still being easy to comprehend. This could be due to my own inexperience though.
It was a long time ago, so I could be misremembering it or confusing it with another model, assuming they haven't changed it since then.
As for the keyboard, I ended up getting a Thinkpad T440p, so that should tell you what my standards are. :P
And this attempt to make a modular phone seems more like a technology demonstration then a product role out. Does anyone think they will try and make a business line out of it? I doubt it.
I think the idea behind Project Ara is the same as the idea behind their Nexus line - they're not interested in being manufacturers, they just want to raise the bar for devices running their software. They'll (hopefully) establish some critical mass, a few other manufacturers will start making parts, and eventually Google won't need to do anything for the system to be self-sustaining, except maybe push for better specs on Ara 2.0...
It's not like you can't add a third party repository with the latest stable (or development) version of Firefox.
Besides, even if you're going to download it somewhere else, would it be good if the OS could check that somewhere else for updates instead of each program have its own auto-update daemon run at startup?
3. C++ isn't an interpreted language; of course it won't have much reflection.
While reflection is much easier to implement in interpreted languages, there are compiled languages that support it. e.g. D
Having worked with D a bit, the biggest difference between it and C++ is that D is garbage collected by default. You can disable the GC and use malloc, but this renders the standard library off limits. Apart from that, I would say that D not only has all the features of C++, it has features that C++ doesn't even have yet. e.g. concepts were proposed as an extension to templates for C++11, but still aren't part of the spec. In contrast, D has support for constraining templates similarly using syntax such as:
T square(T x)
if (isIntegral!T)
{
return x * x;
}
D also has excellent support for functional and meta-programming. e.g. the pure and immutable keywords. While C/C++ requires you to use macros for meta-programming, D lets you use existing D functions to generate the resulting code.
The more interesting question is really if freedom exists when you never make use of it. (Do you actually hack the kernel or fix somebody's proprietary binary-only drivers as a GNU/Linux user?)
You don't need to directly make use of it though; the mere fact that that freedom exists can influence design choices. A good example of this would be how many (common) Linux drivers are based around the actual chip in the device, as opposed to the specific make and model (as is the norm in Windows). Not needing to install drivers for 99% of supported hardware is a pretty nice benefit, and it's the direct result of the kernel (and by extension, those drivers) being GPL.
Freedom, like everything else, exists because it has consequences that we can perceive.
Samsung: http://www.samsung.com/us/seri...
The Series 9 is a POS (or at least it was when I was buying a new laptop a little over a year ago.) The case has a lot of flex and the keyboard terrible tactile response. Regardless of what the specs (and price) are, I don't think you can argue it's a serious contender for the high end.
'cat /proc/filesystems' lists 47 different file systems, which is a superset of those supported by both Windows and OS X.[1] In terms of what you can actually with just one of those, btrfs enables near-instant (~1 second) snapshots of live file systems, which can then be transferred across the network as incremental backups. It also checksums everything stored on the drive so as to eliminate silent corruption. (With the exception of ZFS, pretty much every other FS around is vulnerable to this.)
OS X may (arguably) have some advantages over Linux in terms of usability, but I don't think you can argue that it has a superior feature set. That's the fundamental difference between them - OS X has a few, highly polished features that serve the needs of the average person (who doesn't mind living in an all-Apple ecosystem), while Linux has almost every feature you could think of with a comparatively small amount of polish.[2]
[1] Note that isn't even exhaustive - it only lists those compiled in or with loaded modules.
[2] e.g. There are currently 3+ different ways to use a SSD as a cache for a mechanical drive. None of them have been integrated into the installer for a distro.
Who cares about root! My home directory is WAY more important than the system.
Which means you should have backups that are not writeable by your account, and the easiest way of doing so is having cron create a tarball of /home as root. Alternatively, if you're using btrfs snapshots work great for this.