How is your media encoded? BBC iPlayer HD content is 3.6Mb/s, and even DVD rips are only 10Mb/s. Unless you're streaming BluRay rips (without any recompression), 802.11g should be more than adequate. Even BluRay is only 36Mb/s, which is a bit much for 802.11g in the real world, but well within the capabilities of 802.11n.
pkg-ng does probably address all of the grandparent's complaints. Unfortunately, the security incident means that we don't currently have any binary package sets available (hopefully they'll appear very soon). It's also worth noting that a PackageKit back end for pkg-ng is underway, which should make it easy to use your favourite desktop environment's package management tool on FreeBSD. As most of the pkgng logic is in a shared library, with the pkg tool being a thin wrapper around it, it's very easy to integrate into GUI tools.
This list is a lot smaller if you limit it to countries where English is the native language. I would expect the same sorts of complaints if I translated something into French, but left the number separators in my own locale. Given that almost all of the English-speaking world uses the same thousands and decimal separators, it seems fairly simple to assume that, if you are writing for an English-speaking audience, you should use those.
Intel GPU support is in 9.1 and -CURRENT (10.0). nVidia support is available from their blob. The Nouveau stuff is apparently not much effort to port, but no one has done it. The big omission is AMD, because it depends on TTM, which is not yet implemented in FreeBSD.
It's a bit more complex than that. The goal is an annual goal and is set at the start of the year. In the past, most of the donations have come towards the end of the year, as they did this year, but they've been quietly raising money all year. It's not like the first $400K came in those first four days: most of it came months earlier. One of the priorities for the Foundation in 2013 is encouraging companies to donate earlier (individuals tend to donate at random times anyway, companies when they realise they want a tax write-off at the end of the financial year). It's not finalised yet, but the goal for 2013 is probably going to be $1m.
A number of ZFS developers work on both platforms, so features flow pretty freely between the two. There's also a Linux ZFS implementation maintained in Gentoo, and they're also pretty good at pushing changes in the FreeBSD direction.
The ports infrastructure is written in make, not Ruby. You are probably thinking of portupgrade, which is a (deprecated) third-party tool for managing potrs.
We currently have a few C++ things in the base system:
LLVM/Clang, the biggest bit, which is the C/C++ (and Objective-C) compiler.
libstdc++, libsupc++, libc++ and libcxxrt, which are the old and new STL and C++ runtime libraries, respectively.
devd, which is the utility responsible for performing actions in response to device events (USB device inserted, battery low, and so on).
In a few days, there will also be a BSDL replacement for the GPL'd device tree compiler landing. This is a simple tool that converts between source and flattened device trees, and since it is doing a lot of stuff that involves building maps I decided to use C++ and std::map rather than reinvent the wheel or do something ugly involving macros. Performance isn't an issue, since it's intended to parse input files that are typically under 12KB and produce output that is even smaller, so even without optimisation it uses around 10KB of RAM and under a tenth of a second of CPU time. A higher-level language might have been appropriate, but it's also potentially important to be able to include a statically linked copy for recovery, which rules out most high-level languages.
Note that none of the kernel, and no userland utilities essential for operation are written in C++.
"Nearly $200,000 over" is actually "$180,000" over. I guess 90% is "nearly 100%".
It's currently $184,905K over, and was before TFA was posted. If you're going to be pedantic about rounding, then you probably shouldn't round in your own comment. There are also a few large pledges (e.g. from Netflix), which may or may not arrive in time to be counted towards the 2012 total. If they don't, then the 2013 total will get an early boost. If they do, then they'll easily push it over the $200K-over mark.
In my personal case, I'm looking at a 2.5% rent increase, while the property tax, and water/sewage's increase alone eats it up, include electricity and natural gas? At this rate, I'll be paying to have renters in in a couple years.
Why are you paying any of these? I'm renting out my house at the moment, because I moved to a different city, and my tenant is responsible for the tax, water, electricity, gas, and Internet bills. The money he pays me covers mortgage interest, maintenance costs, and is paying off the capital on the mortgage on top. One of the big savings from renting the house out was that I got to stop paying council tax and utility bills on it.
What do you think the rate on the mortgage is? At 10% (insanely high at the moment), it would be $11.7m/year, which is under half of the income. More plausibly it's a quarter. Don't forget that the loan interest is applied before tax, so that's directly on the income, not on the post-tax profit.
Only as a retail space. There are lots of other uses. That close to Wall Street, I would be surprised if there weren't some HFT firms that would be interested in sticking a data centre in there, for example. At the lower-tech end, there are almost certainly nearby businesses that would like some local storage space: divide it up into large storage lockers and rent it out as overflow storage for any of the nearby retail businesses. Who cares if you're a small hardware store and Home Depot has a big advert over your overflow storage space, none of your customers even know you store stuff there...
AArch64 is the 64-bit instruction set, AArch32 is the 32-bit instruction set. The arm64 designator is usually reserved for CPUs that support AArch64, but currently all of those also support AArch32, so using arm64 for anything other than a kernel or hypervisor is confusing. The 'chaos' around armN is only if you fail to understand that ARMN and ARMvN are different things. For example, ARMv7 is a description of an architecture, ARM11 is an ARM processor design. ARMvN is always a superset of ARMvN-1 in terms of unprivileged instruction set.
The non-builtin ones are typically used for large arguments for memcpy. I'm not familiar with the GCC implementation, but LLVM's memcpy() optimisation knows roughly the cost of a call to memcpy() and will use a sequence of inline loads and stores to avoid the call, but will just call memcpy otherwise. The reason for this is better instruction cache usage. A call to memcpy() requires saving any caller-save registers (this can be cheap, as the register allocator will try to put temporaries that are not used after the call in these registers, so that they don't need to be saved), putting the arguments in registers (this is quite cheap, as they've typically just been used and so the register allocator will try to ensure that they're in the correct registers already), or on the stack on x86 (not too expensive, as push and pop are really register-register moves on modern chips), and of loading the arguments back. For memcpy(), the cost of a single L2 cache miss in the src will likely dwarf the cost of a slow implementation, so it's worth sticking prefetching in very early, if you can. The memcpy() call in position-independent code will be indirect, which means that it will take up an entry in the branch predictor's table. These are a relatively scarce resource - you have something like 512 of them on a modern processor - at each call site.
The ifunc stuff is not necessarily a win, for the same reason. It turns every memcpy() call into an indirect call (or a double-indirect call in PIC), which means that it now needs to go through the branch predictor. This is the kind of thing that is a clear win on microbenchmarks, but has the potential to make real code slower: each ifunc costs either a branch miss (pipeline stall and flush) or a branch target buffer entry (slowing down some other code). Or, in really bad cases, both, because it and another hot function end up trying to use the same BTB entry so you always get a branch miss for both.
I've not used Windows Phone 7 for long enough to really know the UI, but I've played with enough devices to be impressed by the UI (Microsoft Research is the building behind me, so I see a lot of them). It's far from perfect, but then so are iOS and Android, and it's in the same ballpark. In contrast the old WinCE, was a usability disaster. I suspect that their biggest problem is that they only allow.NET code to run, which makes it hard to port code from other platforms to theirs.
June 2010, Freescale announced the ColdFire+ line, which is a ColdFire V1 core using a 90 nm TFS technology
90nm? In 2010? That should be enough to tell you that Freescale doesn't care. A chip announced in 2010 (no idea when, or even if, it actually shipped), using a process that was state of the art in 2002. Cheap parts were using 65nm in 2010. 90nm is the stuff you stick in the fabs that you don't have the spare capital to refurbish and want to keep ticking over. Followed by:
The future of the ColdFire architecture is uncertain given that Freescale has been focusing on ARM-based cores in this market segment
Default as in 'the one that ARM recommend'. The ARM instruction encoding is regarded as legacy compatibility in ARMv7, not as a recommended instruction set for new code.
Not even slightly true. Thumb-2 is the default instruction encoding for all ARMv7 architecture chips (Cortex-A family), because it is capable of representing the entire instruction set, but is denser. The only reason you would use ARM instead of Thumb-2 is that you want to be compatible with ARMv6 (e.g. ARM11 cores on really cheap, low-end, devices).
But many Intel chips have assembly instructions specifically for crazy things like AES encryption.
You picked a pretty poor example, as ARMv8 includes instructions for AES. You should also look at the NEON instruction set on ARM, which has a number of fairly complex floating point operations. The advantage of the microcode on an x86 chip is greater instruction density, meaning less instruction cache usage, so you can have less instruction cache, which means less power consumption. The disadvantage is that you have a significantly more complex instruction decoder, which means more power consumption. The greater instruction density was a big win against more traditional RISC architectures like SPARC, MIPS and Alpha, but is far less so against ARM. For example, address calculation on ARM is about as cheap as on x86 (complex addressing modes were a big win of CISC over RISC when compilers started to use them). In my testing, Thumb-2 code is typically about 10-20% smaller than x86, which means that Intel pays both for bigger instruction caches and for a more complex decoder.
They also don't outsource production, they own their own fabs and make their own chips
Outsourcing production is not necessarily a bad thing, as it allows specialisation. Intel can afford it because they are a big player, but for other companies it makes sense to share the fab R&D costs with others, including with their competitors. They then compete based on their strengths (chip design), and the manufacturers compete based on their process technology.
Female skin apparently has a slightly lower pH than male skin, although I'm not sure why. I don't know if that makes a difference on the effectiveness of the venom, but it may. Bee sting is acidic[1] and so the effect of a bee string is probably slightly strong for women than for men, as their natural skin pH won't neutralise it (conversely, a wasp sting will be milder, as wasp sting is alkaline). Of course, it may just be that they only tested it with women because that's a larger market for cosmetics.
[1] Baking soda for a bee sting, vinegar for a vasp sting, as I recall remembering as a child.
As a C++ programmer, you don't hate C++. You only truly hate the language after trying to implement it and reading the ambiguous, informal description of it that they have the cheek to call a specification.
Slashdot Mirror
How is your media encoded? BBC iPlayer HD content is 3.6Mb/s, and even DVD rips are only 10Mb/s. Unless you're streaming BluRay rips (without any recompression), 802.11g should be more than adequate. Even BluRay is only 36Mb/s, which is a bit much for 802.11g in the real world, but well within the capabilities of 802.11n.
pkg-ng does probably address all of the grandparent's complaints. Unfortunately, the security incident means that we don't currently have any binary package sets available (hopefully they'll appear very soon). It's also worth noting that a PackageKit back end for pkg-ng is underway, which should make it easy to use your favourite desktop environment's package management tool on FreeBSD. As most of the pkgng logic is in a shared library, with the pkg tool being a thin wrapper around it, it's very easy to integrate into GUI tools.
This list is a lot smaller if you limit it to countries where English is the native language. I would expect the same sorts of complaints if I translated something into French, but left the number separators in my own locale. Given that almost all of the English-speaking world uses the same thousands and decimal separators, it seems fairly simple to assume that, if you are writing for an English-speaking audience, you should use those.
Intel GPU support is in 9.1 and -CURRENT (10.0). nVidia support is available from their blob. The Nouveau stuff is apparently not much effort to port, but no one has done it. The big omission is AMD, because it depends on TTM, which is not yet implemented in FreeBSD.
It's a bit more complex than that. The goal is an annual goal and is set at the start of the year. In the past, most of the donations have come towards the end of the year, as they did this year, but they've been quietly raising money all year. It's not like the first $400K came in those first four days: most of it came months earlier. One of the priorities for the Foundation in 2013 is encouraging companies to donate earlier (individuals tend to donate at random times anyway, companies when they realise they want a tax write-off at the end of the financial year). It's not finalised yet, but the goal for 2013 is probably going to be $1m.
A number of ZFS developers work on both platforms, so features flow pretty freely between the two. There's also a Linux ZFS implementation maintained in Gentoo, and they're also pretty good at pushing changes in the FreeBSD direction.
Ruby for ports infrastructure
The ports infrastructure is written in make, not Ruby. You are probably thinking of portupgrade, which is a (deprecated) third-party tool for managing potrs.
We currently have a few C++ things in the base system:
In a few days, there will also be a BSDL replacement for the GPL'd device tree compiler landing. This is a simple tool that converts between source and flattened device trees, and since it is doing a lot of stuff that involves building maps I decided to use C++ and std::map rather than reinvent the wheel or do something ugly involving macros. Performance isn't an issue, since it's intended to parse input files that are typically under 12KB and produce output that is even smaller, so even without optimisation it uses around 10KB of RAM and under a tenth of a second of CPU time. A higher-level language might have been appropriate, but it's also potentially important to be able to include a statically linked copy for recovery, which rules out most high-level languages.
Note that none of the kernel, and no userland utilities essential for operation are written in C++.
"Nearly $200,000 over" is actually "$180,000" over. I guess 90% is "nearly 100%".
It's currently $184,905K over, and was before TFA was posted. If you're going to be pedantic about rounding, then you probably shouldn't round in your own comment. There are also a few large pledges (e.g. from Netflix), which may or may not arrive in time to be counted towards the 2012 total. If they don't, then the 2013 total will get an early boost. If they do, then they'll easily push it over the $200K-over mark.
They make it sound like it's easy to make millions
It's very easy to make millions. As long as you start with billions...
In my personal case, I'm looking at a 2.5% rent increase, while the property tax, and water/sewage's increase alone eats it up, include electricity and natural gas? At this rate, I'll be paying to have renters in in a couple years.
Why are you paying any of these? I'm renting out my house at the moment, because I moved to a different city, and my tenant is responsible for the tax, water, electricity, gas, and Internet bills. The money he pays me covers mortgage interest, maintenance costs, and is paying off the capital on the mortgage on top. One of the big savings from renting the house out was that I got to stop paying council tax and utility bills on it.
What do you think the rate on the mortgage is? At 10% (insanely high at the moment), it would be $11.7m/year, which is under half of the income. More plausibly it's a quarter. Don't forget that the loan interest is applied before tax, so that's directly on the income, not on the post-tax profit.
Only as a retail space. There are lots of other uses. That close to Wall Street, I would be surprised if there weren't some HFT firms that would be interested in sticking a data centre in there, for example. At the lower-tech end, there are almost certainly nearby businesses that would like some local storage space: divide it up into large storage lockers and rent it out as overflow storage for any of the nearby retail businesses. Who cares if you're a small hardware store and Home Depot has a big advert over your overflow storage space, none of your customers even know you store stuff there...
Your numbers only tell part of the story. Try factoring in concentration of wealth and re-running the numbers.
AArch64 is the 64-bit instruction set, AArch32 is the 32-bit instruction set. The arm64 designator is usually reserved for CPUs that support AArch64, but currently all of those also support AArch32, so using arm64 for anything other than a kernel or hypervisor is confusing. The 'chaos' around armN is only if you fail to understand that ARMN and ARMvN are different things. For example, ARMv7 is a description of an architecture, ARM11 is an ARM processor design. ARMvN is always a superset of ARMvN-1 in terms of unprivileged instruction set.
The non-builtin ones are typically used for large arguments for memcpy. I'm not familiar with the GCC implementation, but LLVM's memcpy() optimisation knows roughly the cost of a call to memcpy() and will use a sequence of inline loads and stores to avoid the call, but will just call memcpy otherwise. The reason for this is better instruction cache usage. A call to memcpy() requires saving any caller-save registers (this can be cheap, as the register allocator will try to put temporaries that are not used after the call in these registers, so that they don't need to be saved), putting the arguments in registers (this is quite cheap, as they've typically just been used and so the register allocator will try to ensure that they're in the correct registers already), or on the stack on x86 (not too expensive, as push and pop are really register-register moves on modern chips), and of loading the arguments back. For memcpy(), the cost of a single L2 cache miss in the src will likely dwarf the cost of a slow implementation, so it's worth sticking prefetching in very early, if you can. The memcpy() call in position-independent code will be indirect, which means that it will take up an entry in the branch predictor's table. These are a relatively scarce resource - you have something like 512 of them on a modern processor - at each call site.
The ifunc stuff is not necessarily a win, for the same reason. It turns every memcpy() call into an indirect call (or a double-indirect call in PIC), which means that it now needs to go through the branch predictor. This is the kind of thing that is a clear win on microbenchmarks, but has the potential to make real code slower: each ifunc costs either a branch miss (pipeline stall and flush) or a branch target buffer entry (slowing down some other code). Or, in really bad cases, both, because it and another hot function end up trying to use the same BTB entry so you always get a branch miss for both.
I've not used Windows Phone 7 for long enough to really know the UI, but I've played with enough devices to be impressed by the UI (Microsoft Research is the building behind me, so I see a lot of them). It's far from perfect, but then so are iOS and Android, and it's in the same ballpark. In contrast the old WinCE, was a usability disaster. I suspect that their biggest problem is that they only allow .NET code to run, which makes it hard to port code from other platforms to theirs.
June 2010, Freescale announced the ColdFire+ line, which is a ColdFire V1 core using a 90 nm TFS technology
90nm? In 2010? That should be enough to tell you that Freescale doesn't care. A chip announced in 2010 (no idea when, or even if, it actually shipped), using a process that was state of the art in 2002. Cheap parts were using 65nm in 2010. 90nm is the stuff you stick in the fabs that you don't have the spare capital to refurbish and want to keep ticking over. Followed by:
The future of the ColdFire architecture is uncertain given that Freescale has been focusing on ARM-based cores in this market segment
Exactly.
Default as in 'the one that ARM recommend'. The ARM instruction encoding is regarded as legacy compatibility in ARMv7, not as a recommended instruction set for new code.
Not even slightly true. Thumb-2 is the default instruction encoding for all ARMv7 architecture chips (Cortex-A family), because it is capable of representing the entire instruction set, but is denser. The only reason you would use ARM instead of Thumb-2 is that you want to be compatible with ARMv6 (e.g. ARM11 cores on really cheap, low-end, devices).
But many Intel chips have assembly instructions specifically for crazy things like AES encryption.
You picked a pretty poor example, as ARMv8 includes instructions for AES. You should also look at the NEON instruction set on ARM, which has a number of fairly complex floating point operations. The advantage of the microcode on an x86 chip is greater instruction density, meaning less instruction cache usage, so you can have less instruction cache, which means less power consumption. The disadvantage is that you have a significantly more complex instruction decoder, which means more power consumption. The greater instruction density was a big win against more traditional RISC architectures like SPARC, MIPS and Alpha, but is far less so against ARM. For example, address calculation on ARM is about as cheap as on x86 (complex addressing modes were a big win of CISC over RISC when compilers started to use them). In my testing, Thumb-2 code is typically about 10-20% smaller than x86, which means that Intel pays both for bigger instruction caches and for a more complex decoder.
They also don't outsource production, they own their own fabs and make their own chips
Outsourcing production is not necessarily a bad thing, as it allows specialisation. Intel can afford it because they are a big player, but for other companies it makes sense to share the fab R&D costs with others, including with their competitors. They then compete based on their strengths (chip design), and the manufacturers compete based on their process technology.
Glib is a tool for people who have a problem for which C is not the correct tool, yet insist on trying to use C.
Female skin apparently has a slightly lower pH than male skin, although I'm not sure why. I don't know if that makes a difference on the effectiveness of the venom, but it may. Bee sting is acidic[1] and so the effect of a bee string is probably slightly strong for women than for men, as their natural skin pH won't neutralise it (conversely, a wasp sting will be milder, as wasp sting is alkaline). Of course, it may just be that they only tested it with women because that's a larger market for cosmetics.
[1] Baking soda for a bee sting, vinegar for a vasp sting, as I recall remembering as a child.
As a C++ programmer, you don't hate C++. You only truly hate the language after trying to implement it and reading the ambiguous, informal description of it that they have the cheek to call a specification.