As a final note, the ports collection on FreeBSD appears to be the Gentoo linux dream achieved. Just tick boxes instead of choosing compile flags.
Note that, if you want to compile ports yourself, it's now *strongly* recommended to use Poudriere rather than compiling individual ports stand-alone. Poudriere can compile any subset of the ports tree you want and give you a consistent package set. Poudriere builds ports in a jail so they won't ever accidentally be affected by other things on your system and will always only have the dependencies that are explicitly set. You can then install the packages alongside the upstream ones or, if you want to do something more interesting (e.g. building everything with a different compiler) build just the ones that you want.
I'm a bit confused by KMS/Qemu. Do you mean KVM or KMS? Kernel Mode Switching (KMS) has been in FreeBSD since 10.0 and the graphics drivers are now very close to parity with Linux. If you mean KVM, FreeBSD ships with bhyve, the BSD Hypervisor, which is a legacy-free Type II hypervisor. It happily runs Linux and FreeBSD as guests and will run Windows Vista or newer with a little bit of fiddling. VirtualBox also works well on FreeBSD, if you want something more desktop friendly and FreeBSD works as a Xen Domain 0 if you want something a bit more cloudy.
I was a bit surprised about that, as my FreeBSD 10 machine has had working 802.11n since 10.0 (support was in head for a long time, but Adrian doesn't like to do MFCs so it took a while to make it into a release).
Add to that, recent x86 chips can do XOR in the DMA engine, so you actually have hardware RAID built into your CPU with a direct connection to the DRAM. Replacing it with one that's dangled off the PCIe bus doesn't sound too sensible.
If you're a human, your reply will be something like 'I don't remember exactly, something about...'. If you're an AI, you'll be able to repeat the sentence verbatim. If you're a crappy chat bot that's little more complex than Eliza, then you'll evade the question with some meaningless tangent.
"The Russians are trying to hack everything." No evidence, but you sure hear it a lot, so it seems true.
No, there's plenty of evidence. There's also plenty of evidence that the USA, UK, China, and so on, are trying to hack everything. What do you think the NSA, GCHQ, and friends do all day?
Oh, but of course, we're expected to rewrite every application where every box a user could type an international name or address or text has a separate drop down to select a language. That's totally less exasperating.
No you're not. If it's a desktop application, you get the locale from the local user's settings. If it's a web application, you get it from the Accept-Language HTTP request header field. And then you just use that. Since POSIX 2008, even libc has contained thread-safe interfaces for locale-aware sorting. If you're using a database that doesn't support locale-aware collation, then I suggest that you find one that doesn't suck: PostgreSQL has had support for it for well over a decade and can use either libc or ICU, so if your libc implementation is too slow it will still perform well (though with an extra dependency).
Storage is cheap, bandwidth is often not. When you're downloading 500KB of a JavaScript library for multiple different sites, that adds up quickly on mobile devices. It also adds to the page load times - the odds are your users will have cached the thing from Google already, so it doesn't add anything to their load times. Additionally, for JavaScript, it's possible to store commonly-used libraries in pre-parsed form (Safari will keep the bytecode for cached JavaScript libraries for a while), which also improves performance.
Sure, and also the freedom to be a lying leftard knee-jerk SJW. They go hand in hand
No they don't. If you believe in free speech, you must believe in free speech for people that disagree with you, but just because you believe in having the right to say certain things doesn't mean that you believe in free speech. Milo definitely believes in his right to say certain things. He's far less into other people having the right to say things that contradict him.
Best course of action --- ask female computer science people (and I don't mean a person who brought Microsoft Bob to an unsuspecting world, but real female computer science people) what obstacles they faced and what would they do to remove them.
The problem with this is survivor bias: you're only asking the ones that either didn't have the obstacles or overcame them.
It took a couple of pages of maths, and because I am not very good at maths it took me a while, but it was worth the effort.
Was it really? The difficult bit was forming the differential equation that solved the problem. After that, typing it into something like GNU Octave would give you the answer in less time than it took to ask the question. Solving it yourself on a piece of paper may have been fun (if that's your idea of fun), but I doubt very much that it was faster or gave a better answer.
Do you actually solve them, or do you ask a computer to? When you solve one by hand, you're running a fairly simple algorithm that's trivial to program into a computer, which then won't make mistakes applying the various rules. There are several off-the-shelf packages that can do it, including several open source ones. I've occasionally had to construct differential equations for things since leaving school, but I've never felt the need to solve one by hand and somewhat resent the fact that the education system made me spend a year going from solving them n orders of magnitude slower than a computer to solving them n-1 orders of magnitude slower (where n varies as computers get faster, but was always at least 3-4).
Pretty much all vaguely modern ARM SoCs have FDT in the firmware (some of the server-oriented ARMv8 ones use ACPI instead). This provides the default memory maps, the locations of devices, the names of the drivers needed to use those devices, and so on. They also all typically now use an ARM GIC (earlier ARM SoCs often used incompatible vendor-provided interrupt controllers, which made life a bit more painful) or, if not the ARM implementation, something that exposes the same interfaces.
ARM has done a huge amount in terms of ecosystem standardisation over the last decade. Linus sounds like he hasn't looked at ARM since 2005.
That was certainly true in the ARMv4-5 time. It's somewhat true for ARMv6. For ARMv7 and ARMv8, it's far less true. There's a lot of standardisation of bootloaders, interrupt controllers, and so on, to the extent that FreeBSD is now able to ship a single kernel for relatively modern (RPi and newer) ARM devices that selects drivers based on the FDT or ACPI in the same way that the x86 kernel does with ACPI.
This font is intended as the fallback font. When the currently selected font doesn't have a glyph for the desired codepoint, your font engine will provide a substitute. It will start with similar styles (e.g. sans serif, monospace) and if that fails it will fall back to a generic font that has large coverage. That's the point of this font. If you're using it for most of the glyphs you're rendering, then you're doing it wrong.
If you want a good font for programming, Adobe released Source Code Pro a couple of years ago under the SIL Open Font License, and it's the nicest that I've found so far.
The entire point of unicode is that the glyphs are separate from the codepoints. The codepoints (defined by the unicode spec) convey semantics, not presentation. There are lots of different (valid) ways of representing each codepoint (if there weren't, then you wouldn't need fonts at all).
Then along came emojis and the entire clusterfuck that led to.
Aside from the character looking wrong in Chinese or Japanese (whichever language you don't have installed as default) they may sort differently in different languages so collation is wrong too.
Collation shouldn't be broken. Collation is always locale-specific. German, English, and French all have different collation orders, even though they're using the same character set (how you sort capitals vs lower case vs accented variants is different in each). The only reason that this would break collation would be if, for example, Japanese sorts Chinese characters differently from the equivalent Kanji (does it? I have no idea).
It's not always laziness (or tracking, from Google's perspective). Google sets a long cache value for most of these resources. If 10 different sites all host them individually, then someone visiting the site will have to download the fonts 10 times. Alternatively, if they all point to Google then they'll download once and cache the copy locally for the other 9 sites.
There was a proposal a couple of years ago to embed a cryptographic hash of the resource in the link. This would allow you to specify a download location, but if you've already downloaded the file from another source then you could still use it (it would also make caches more efficient, because you could set an infinite timeout and make clients redownload by having a different hash in the link - clients would keep their copy potentially forever, until you updated the version). I don't know of any browsers that implemented it though.
He's probably thinking of the 486DX. The original 486 had an FPU, but the yields were low so Intel split the line into the 486SX (no FPU) and the 486DX (with FPU). Some motherboards let you plug in a 487 as an external FPU, but this was often really just a 486DX that took over completely. The 486SX was identical to the DX, but had the FPU disabled. It was possible to reenable it, and it would typically work most of the time. For gaming, this was fine (the occasional floating point error probably didn't make a difference) and was a cheap way of getting much more performance.
You are absolutely right. No concentration of power in the hands of a few individuals has ever been abused. Certainly there's no history of NSA operatives abusing their agency's capabilities to spy on individuals for personal reasons. There's also no history of the FBI creating files to blackmail members of the government and influence policy. Nothing to see, move along.
Slashdot Mirror
As a final note, the ports collection on FreeBSD appears to be the Gentoo linux dream achieved. Just tick boxes instead of choosing compile flags.
Note that, if you want to compile ports yourself, it's now *strongly* recommended to use Poudriere rather than compiling individual ports stand-alone. Poudriere can compile any subset of the ports tree you want and give you a consistent package set. Poudriere builds ports in a jail so they won't ever accidentally be affected by other things on your system and will always only have the dependencies that are explicitly set. You can then install the packages alongside the upstream ones or, if you want to do something more interesting (e.g. building everything with a different compiler) build just the ones that you want.
I'm a bit confused by KMS/Qemu. Do you mean KVM or KMS? Kernel Mode Switching (KMS) has been in FreeBSD since 10.0 and the graphics drivers are now very close to parity with Linux. If you mean KVM, FreeBSD ships with bhyve, the BSD Hypervisor, which is a legacy-free Type II hypervisor. It happily runs Linux and FreeBSD as guests and will run Windows Vista or newer with a little bit of fiddling. VirtualBox also works well on FreeBSD, if you want something more desktop friendly and FreeBSD works as a Xen Domain 0 if you want something a bit more cloudy.
I was a bit surprised about that, as my FreeBSD 10 machine has had working 802.11n since 10.0 (support was in head for a long time, but Adrian doesn't like to do MFCs so it took a while to make it into a release).
Add to that, recent x86 chips can do XOR in the DMA engine, so you actually have hardware RAID built into your CPU with a direct connection to the DRAM. Replacing it with one that's dangled off the PCIe bus doesn't sound too sensible.
It's able to lie about being sentient and having a soul, that makes it perfectly qualified!
If you're a human, your reply will be something like 'I don't remember exactly, something about...'. If you're an AI, you'll be able to repeat the sentence verbatim. If you're a crappy chat bot that's little more complex than Eliza, then you'll evade the question with some meaningless tangent.
"The Russians are trying to hack everything." No evidence, but you sure hear it a lot, so it seems true.
No, there's plenty of evidence. There's also plenty of evidence that the USA, UK, China, and so on, are trying to hack everything. What do you think the NSA, GCHQ, and friends do all day?
Oh, but of course, we're expected to rewrite every application where every box a user could type an international name or address or text has a separate drop down to select a language. That's totally less exasperating.
No you're not. If it's a desktop application, you get the locale from the local user's settings. If it's a web application, you get it from the Accept-Language HTTP request header field. And then you just use that. Since POSIX 2008, even libc has contained thread-safe interfaces for locale-aware sorting. If you're using a database that doesn't support locale-aware collation, then I suggest that you find one that doesn't suck: PostgreSQL has had support for it for well over a decade and can use either libc or ICU, so if your libc implementation is too slow it will still perform well (though with an extra dependency).
Storage is cheap, bandwidth is often not. When you're downloading 500KB of a JavaScript library for multiple different sites, that adds up quickly on mobile devices. It also adds to the page load times - the odds are your users will have cached the thing from Google already, so it doesn't add anything to their load times. Additionally, for JavaScript, it's possible to store commonly-used libraries in pre-parsed form (Safari will keep the bytecode for cached JavaScript libraries for a while), which also improves performance.
Knowing nothing more about them man than what you've posted, he still doesn't sound as bad as the R and D candidates.
Sure, and also the freedom to be a lying leftard knee-jerk SJW. They go hand in hand
No they don't. If you believe in free speech, you must believe in free speech for people that disagree with you, but just because you believe in having the right to say certain things doesn't mean that you believe in free speech. Milo definitely believes in his right to say certain things. He's far less into other people having the right to say things that contradict him.
Halal, perhaps?
Best course of action --- ask female computer science people (and I don't mean a person who brought Microsoft Bob to an unsuspecting world, but real female computer science people) what obstacles they faced and what would they do to remove them.
The problem with this is survivor bias: you're only asking the ones that either didn't have the obstacles or overcame them.
It took a couple of pages of maths, and because I am not very good at maths it took me a while, but it was worth the effort.
Was it really? The difficult bit was forming the differential equation that solved the problem. After that, typing it into something like GNU Octave would give you the answer in less time than it took to ask the question. Solving it yourself on a piece of paper may have been fun (if that's your idea of fun), but I doubt very much that it was faster or gave a better answer.
Do you actually solve them, or do you ask a computer to? When you solve one by hand, you're running a fairly simple algorithm that's trivial to program into a computer, which then won't make mistakes applying the various rules. There are several off-the-shelf packages that can do it, including several open source ones. I've occasionally had to construct differential equations for things since leaving school, but I've never felt the need to solve one by hand and somewhat resent the fact that the education system made me spend a year going from solving them n orders of magnitude slower than a computer to solving them n-1 orders of magnitude slower (where n varies as computers get faster, but was always at least 3-4).
If an algorithm is I/O-bound, running it on a faster processor with slower I/O will likely not make it faster.
Your post is still entirely true if you delete all occurrences of the word 'ARM'.
Pretty much all vaguely modern ARM SoCs have FDT in the firmware (some of the server-oriented ARMv8 ones use ACPI instead). This provides the default memory maps, the locations of devices, the names of the drivers needed to use those devices, and so on. They also all typically now use an ARM GIC (earlier ARM SoCs often used incompatible vendor-provided interrupt controllers, which made life a bit more painful) or, if not the ARM implementation, something that exposes the same interfaces.
ARM has done a huge amount in terms of ecosystem standardisation over the last decade. Linus sounds like he hasn't looked at ARM since 2005.
That was certainly true in the ARMv4-5 time. It's somewhat true for ARMv6. For ARMv7 and ARMv8, it's far less true. There's a lot of standardisation of bootloaders, interrupt controllers, and so on, to the extent that FreeBSD is now able to ship a single kernel for relatively modern (RPi and newer) ARM devices that selects drivers based on the FDT or ACPI in the same way that the x86 kernel does with ACPI.
This font is intended as the fallback font. When the currently selected font doesn't have a glyph for the desired codepoint, your font engine will provide a substitute. It will start with similar styles (e.g. sans serif, monospace) and if that fails it will fall back to a generic font that has large coverage. That's the point of this font. If you're using it for most of the glyphs you're rendering, then you're doing it wrong.
If you want a good font for programming, Adobe released Source Code Pro a couple of years ago under the SIL Open Font License, and it's the nicest that I've found so far.
Then along came emojis and the entire clusterfuck that led to.
Aside from the character looking wrong in Chinese or Japanese (whichever language you don't have installed as default) they may sort differently in different languages so collation is wrong too.
Collation shouldn't be broken. Collation is always locale-specific. German, English, and French all have different collation orders, even though they're using the same character set (how you sort capitals vs lower case vs accented variants is different in each). The only reason that this would break collation would be if, for example, Japanese sorts Chinese characters differently from the equivalent Kanji (does it? I have no idea).
It's not always laziness (or tracking, from Google's perspective). Google sets a long cache value for most of these resources. If 10 different sites all host them individually, then someone visiting the site will have to download the fonts 10 times. Alternatively, if they all point to Google then they'll download once and cache the copy locally for the other 9 sites.
There was a proposal a couple of years ago to embed a cryptographic hash of the resource in the link. This would allow you to specify a download location, but if you've already downloaded the file from another source then you could still use it (it would also make caches more efficient, because you could set an infinite timeout and make clients redownload by having a different hash in the link - clients would keep their copy potentially forever, until you updated the version). I don't know of any browsers that implemented it though.
He's probably thinking of the 486DX. The original 486 had an FPU, but the yields were low so Intel split the line into the 486SX (no FPU) and the 486DX (with FPU). Some motherboards let you plug in a 487 as an external FPU, but this was often really just a 486DX that took over completely. The 486SX was identical to the DX, but had the FPU disabled. It was possible to reenable it, and it would typically work most of the time. For gaming, this was fine (the occasional floating point error probably didn't make a difference) and was a cheap way of getting much more performance.
You are absolutely right. No concentration of power in the hands of a few individuals has ever been abused. Certainly there's no history of NSA operatives abusing their agency's capabilities to spy on individuals for personal reasons. There's also no history of the FBI creating files to blackmail members of the government and influence policy. Nothing to see, move along.