And (at least legally, there may be some exceptions), none of the code in these proprietary products was relicensed. It is built and shipped in accordance with the terms of the license, which permits redistribution in proprietary form as long as you provide attribution, don't sue the original developers if it doesn't work, and don't use their names to advertise your product. The fact that the overall work may have a different license from its components is a different issue. This is why detractors call the GPL 'viral', in that it (more or less) requires any work that contains GPL'd components to be GPL'd.
Yes, well known and accepted. The craptastic GCC developers have been hurting its improvements for years. They have serious control freak issues and as such, GCC has fallen well behind the curve. This isn't a new topic of discussion.
I'm a clang developer and you're a troll. Clang is faster than GCC on some benchmarks. GCC is faster than clang on others. The new autovectorisation code in Clang is usually faster than GCC, sometimes a lot faster, occasionally slower. Clang doesn't yet have the OpenMP support upstream. In most real-world code you won't see a difference of more than 10% between them, and even then you won't see a consistent winner.
I don't like GCC, and I don't use GCC (except on MIPS, where clang isn't quite ready), but GCC is not 'well behind the curve', it still gives acceptable performance. It was never the fastest player (ICC, XLC and Open64 were all faster), but it's pretty respectable.
I was a clang committer before I joined the FreeBSD project. I became a clang committer because I wanted an Objective-C compiler that supported a modern dialect of the language for non-Apple platforms. I took a look at the Objective-C code in gcc. It mingles parsing, semantic analysis and code generation in a convoluted knot. After a week of failing to understand it, I took at look at clang. At the time, Clang has parsing support for Objective-C, but no code generation support at all. Within a week, having never looked at the Clang codebase before, I had it generating code for a superset of the language that GCC supported.
I've also use clang to do syntax highlighting, to inspect files for type information for use in an FFI for a JIT-compiled language, and as a static analyser. How many tools have you seen that are based on GCC and aren't compilers?
Performance isn't the only metric by which you judge compilers, although I agree that it's an important one. OpenMP support affects a very small number of programs. Intel has just open sourced (BSDL) their OpenMP runtime and is pushing patches into clang, so that support should appear soon. The rest of the benchmarks show very little performance difference between clang 3.3 (which is in FreeBSD 10.0) and gcc 4.8, and neither is a clear winner in all cases. In comparison to the last GPLv2 GCC (4.2.1), which FreeBSD currently ships, both are significantly faster. If you need OpenMP today, gcc 4.8 is in ports, so just install the lang/gcc48 port and use it.
However, as I said, performance is not the only metric. Clang has full support for C++11 and supports more of C11 than GCC (for example, it correctly supports _Atomic and it supports _Generic). In FreeBSD, we're now using _Generic in a number of system headers and so you get better error reporting if your compiler supports them (fallback code exists if it doesn't). We found a few logic bugs in ports as a result of this, some of which have existed on other platforms and compiled without warnings for years. So, if you want to use the latest versions of C, C++, or Objective-C, clang is a better choice for you. We're also now shipping libc++ as the default C++ standard library, so we have a complete C++11 stack.
If you're developing C-family code and don't have a Coverity license, then having the clang static analyser around is also very helpful (it's built into clang, so you get it as part of the default install).
Apple doesn't directly fund FreeBSD, but they do sometimes contribute code. For example, most of the MAC framework (SEBSD) was funded by Apple and developed for both FreeBSD and OS X (the pluggable policy stuff in that makes the sandboxing for iOS and Mac App Store apps possible). When Apple wants kernel code written, they often contract work to FreeBSD devs, and are sometimes willing to fund the FreeBSD version at the same time because code that's generic enough to work on both kernels.
Lots of our downstream consumers (especially embedded systems companies) have a policy of 'no GPLv3 on the premises'. They don't want the potential liability, and they especially don't want to make it easy for them to accidentally distribute GPLv3 code. Even if they're not planning on shipping GCC in their product (and, by the way, a lot of them do ship toolchains - embedded also includes companies like NetApp and Juniper - as it makes servicing easier), there's the potential to do it accidentally if the code is sitting there on developers' machines.
Someone else has already pointed you at the report on the compromise. One of our developers has a VM that turned out not to be as secure as he though, and which had his ssh keys (with no passphrase) that gave access to the FreeBSD cluster machines. As soon as the attack was noticed (very quickly, owing to one particularly paranoid developer), the affected machines were taken offline. Bringing things back online took a long time, for several reasons:
All of the code that we're running on FreeBSD.org machines was audited
Some of it turned out to be a little bit scary (e.g. build machines having access to the FTP servers so they could push packages) and so the architecture needed redesigning in places.
We rolled out auditdistd on all of the hosted machines, so now they have audit logs that are stored in multiple places, for all machines.
We redesigned the network layout at all of our sites to reduce interconnectivity of unrelated services.
As to the codebase needing auditing, we had both svn and git mirrors that allowed the entire history to be checked. We also had copies of checksums of releases and so all of these things were verified. Bringing CVS back online took a bit longer, as CVS easily let us verify the top of the tree, but not the history. I think we ended up regenerating the entire CVS history from svn, and took the opportunity to officially remove support for CVS.
Are there still vulnerabilities? Almost certainly. Any codebase more than a few dozen lines long will contain bugs, and some of them are exploitable if you're sufficiently clever. That's why a lot of the focus in 10.0 has been on mitigation techniques. The auditdistd framework lets you easily deploy auditing for an entire site. Capsicum makes it relatively easy to compartmentalise applications and a system daemons use capsicum out of the box. So do some of the normal filter utilities, for example even if you run uniq as a root user, once it's finished parsing the command line arguments it won't be able to access to any files in your system except the ones you told it to read.
There are several things that make your post look like a troll:
Which BSD are you referring to? There's some overlap between the BSD communities, but only about as much as there is between the communities of various Linux distributions.
Where did you ask? Was it one of the places that FreeBSD recommends (mailing lists, IRC channels, or forums), or did you just pick a random place somewhere on the Internet?
Did you actually read the FreeBSD Handbook, which contains fairly detailed instructions on installation, or is that one of the documents that wasn't 'written in some semblance of English'.
They've literally deprecated fork, because they can't be bothered to make it work reliably with Core Framework
fork() deserves to be deprecated. The API originates with old machines that could have a single process in-core at a time. When you wanted to switch processes, you wrote the current process out and read the new one in. In this context, fork was the cheapest possible way of creating a new process, because you just wrote out the current process, tweaked the process control block, and continued executing. On a modern machine, it requires lots of TLB churn as you mark the entire process as copy-on-write (including TLB shootdowns which require IPIs on a multithreaded program using multiple cores). And then, in most cases, it's followed by exec() and so the process that you've just created is replaced by another one and you need to go through the whole sequence again to stop its memory being CoW.
Not only is fork() a ludicrously inefficient way of creating a process on a modern machine, it's also incredibly difficult to use correctly. When you fork(), all of your threads and all of your process descriptors are copied. You need to make sure that every thread that you create uses pthread_atfork() to ensure that it doesn't do any I/O after the fork() and before the exec(). You also need to ensure that you close any file descriptors that you don't want to be propagated to the child, which is nontrivial if you have other threads opening and closing files in the background (O_CLOEXEC helps here, but do you remember to use it everywhere?).
Oh, and posix_spawn() isn't much better. It's designed to be possible to implement on top of existing APIs and so ends up being largely useless without non-standard additions. It doesn't, for example, provide a mechanism to say 'close all file descriptors in the child, except for these ones'.
Sounds like the Brave New World solution is required. Stop demonising drugs, and make freely available drugs that give a sense of euphoria and lethargy. If people don't want to do anything with their lives other than take drugs, then let them get on with it in a non-destructive (to people other than themselves) way and remove themselves painlessly from the gene pool.
2: Flash will always be 10x cost of harddrives. In other words, Flash won't overtake harddrives on price.
That's assuming that hard drives keep getting bigger and cheaper. The amount of R&D money required for each generation of improvement (in most technology) goes up, but the spending for HDDs has gone down as manufacturers see that they're hitting diminishing returns. The number of people who will pay for 4TB disks is lower than the number that will pay for 2TB, which is lower than the number that will pay for 1TB disks and so on. For a lot of users, even 500GB is more than they will need for the lifetime of a disk.
The minimum costs for an SSD are lower than the minimum costs for an HDD. Currently, the smallest disks I can find are about 300GB, and they cost about as much as a 64GB SSD. If you bring an 8TB disk to market now, you're betting that enough people will buy it at a premium price to recoup your R&D expenses before SSDs (Flash or some other technology) pass it in capacity. But now, a lot of the people who traditionally bought the high-end disks are buying SSDs and they're caring more about latency and throughput than capacity. If you show an insanely expensive disk that gives 10x the capacity of the current best, most of these people will say 'meh,' but if you show them a disk that can do 10x the IOPS then they'll ask how much and how soon you can deliver. This gives a big incentive to concentrate R&D spending on SSDs.
It's not unproductive. There are lots of advantages of SSDs over HDDs, and only one advantage of HDDs over SSDs: price per unit capacity. Saying that comparing price per GB doesn't add anything to the conversation is like saying that comparing IOPS doesn't add anything to the conversation. If you remove price comparisons, then there is no reason to think about HDDs at all. The only reason that I have any HDDs today is that SSDs of a similar capacity are not cost effective. Price per GB is the reason that my laptop uses an SSD, but my NAS uses three HDDs: the SSD for my laptop added about 10% to the price, doing the same for my NAS would have added over 1000% to the price. If SSDs were within a factor of 2 of the price of HDDs, I'd have bought SSDs instead.
Thank you for all of your posts in this thread. I've enjoyed a lot of Timothy Zahn books, but you've done a very good job of convincing me not to put any money into this.
I bought FTL when it was discounted on GOG. Horribly addictive. Don't start playing it if you have anything important to do over the next few days. It's amazingly simple in design - probably the highest ratio of player enjoyment to developer time of any game I've played in years.
Depends on their market segment. Apple already has the infrastructure in place for shipping fat binaries (sorry, 'universal binaries'). If they can persuade developers to ship x86-64 and ARMv8 fat binaries then a MacBook Air with a quad ARMv8 SoC and a touchscreen (and the ability to run iOS and OS X apps) might be a very interesting device. It would be seriously underpowered in comparison to the MacBook Pro, but the current MacBook Air is anyway.
Very little iOS software is written in assembly. It's mostly written in Objective-C, with some C and C++. From the perspective of these languages, architecture differences are:
Size of various primitive types.
Alignment of primitive types.
Endian.
Ability to do unaligned loads and stores.
Between x86-32 and ARMv7, these are all the same (well, the cost of unaligned loads and stores is more on ARM). Between x86-64 and ARMv8, they are the same. This also means that you can trivially share memory-mapped data between the two. If you were to ship a laptop with some ARMv8 cores and some x86-64 cores on cache-coherent memory interface, then you could trivially translate system calls made on the ARM chip into system calls delivered to the x86-64 operating system - you'd need to tweak the call frame, but any of the data passed by pointer would be readable by the kernel (actually, this doesn't necessarily require cache coherency, as the OS X kernel always explicitly copies data in and out via some well-defined code paths). You could also use shared memory and Mach ports to communicate between the application and the window server.
In fact, given the comparatively stateless nature of the OS X window server, it would be conceivable to have the ability to dynamically switch between a window server running on the ARM core (when in low-power mode, checking email or whatever) or the x86 core (when doing real work).
That depends a lot on what you want to work on. For some things, there are a very few institutions that specialise in a particular field, and if the reason you picked your undergraduate university was that they're world leaders in something you're interested in then you'd be crazy to go elsewhere. Similarly, if you're already at a top university then there often aren't many places where you can go that aren't a step down or don't require relocating to a different country (which may or may not be desirable).
Even if your good students do go elsewhere, if you encourage them to do a PhD somewhere then they're likely to come into contact with good undergrads at their new institution, and when those students are considering somewhere to go then you want your former undergrads to put you in touch with them.
A debug build of LLVM generates over 2GB for the debug info. Much of this is removed by the linker. For FreeBSD, it's the userland for 6 architectures when I'm doing a test build and a few dozen kernel configs. It adds up quickly.
That's true to a degree, but teaching and research (and publications) are not as separate as you might see. If you're a lecturer, a lot of your publications are going to be things that you've coauthored with your PhD or MPhil students. And the easiest way to get PhD students is to encourage your undergraduates to apply to continue studying with you (or apply for postgraduate research assistant jobs). The undergrad teaching is how you get the PhD students, and they're how you get significant quantities of research done.
Uh, what? Compiling is so fast on an existing, consumer-grade laptop with an SSD that for incremental builds it's a productivity boost, and it works when I'm at home, at work, on the train, or whatever. The difference in price between the SSD and a mechanical disk was about £300, two years ago (for a 256GB disk). It's now even lower. When I'm doing a lot of builds in different configurations I'll use a centralised server. When I'm actually hacking, I want my working copy to be local. The entire point is to speed up the edit-compile-test cycle, and sticking a network in the middle does not do that.
I have a build machine that has 24 cores, 256GB of RAM, 256GB of SSD, and 4TB of spinning rust. Building on the SSD is significantly faster than the spinning rust (factor of 2-4 depending on what you're building). Building on the RAM disk is probably 1-2% faster, but within the noise for subsequent runs. I often put the object files on the RAM disk though. It doesn't seem to impact performance, but it means that the OS never has to bother writing them out to disk, which should help the SSD last longer when I'm generating 2-30GB of object files per build.
I do, and so does everyone else on my corridor. Yes, we also have machines in racks that can build things faster, but with a quad-core i7 and an SSD in my laptop, I can build the LLVM codebase in 5-10 minutes, with incremental builds often taking under a minute, and that's a big win for my productivity over spinning rust. Most software projects that I work on have been ongoing for 10 or more years and in that time even a small team can produce something that has thousands of source files.
If you're compiling a single file, not doing a parallel build, and having all of the headers already in cache, then you'll probably see about that kind of speedup. If, however, since this isn't the 1960s anymore, you're working on a codebase with a few hundreds or thousands of files, doing a parallel build, then you'll likely see your builds take about half as long. Less if you have a faster processor, because they're now going to be totally CPU limited and not I/O bound.
Slashdot Mirror
Why would you point to the tarball location, when the revision control system is online?
And (at least legally, there may be some exceptions), none of the code in these proprietary products was relicensed. It is built and shipped in accordance with the terms of the license, which permits redistribution in proprietary form as long as you provide attribution, don't sue the original developers if it doesn't work, and don't use their names to advertise your product. The fact that the overall work may have a different license from its components is a different issue. This is why detractors call the GPL 'viral', in that it (more or less) requires any work that contains GPL'd components to be GPL'd.
Yes, well known and accepted. The craptastic GCC developers have been hurting its improvements for years. They have serious control freak issues and as such, GCC has fallen well behind the curve. This isn't a new topic of discussion.
I'm a clang developer and you're a troll. Clang is faster than GCC on some benchmarks. GCC is faster than clang on others. The new autovectorisation code in Clang is usually faster than GCC, sometimes a lot faster, occasionally slower. Clang doesn't yet have the OpenMP support upstream. In most real-world code you won't see a difference of more than 10% between them, and even then you won't see a consistent winner.
I don't like GCC, and I don't use GCC (except on MIPS, where clang isn't quite ready), but GCC is not 'well behind the curve', it still gives acceptable performance. It was never the fastest player (ICC, XLC and Open64 were all faster), but it's pretty respectable.
I was a clang committer before I joined the FreeBSD project. I became a clang committer because I wanted an Objective-C compiler that supported a modern dialect of the language for non-Apple platforms. I took a look at the Objective-C code in gcc. It mingles parsing, semantic analysis and code generation in a convoluted knot. After a week of failing to understand it, I took at look at clang. At the time, Clang has parsing support for Objective-C, but no code generation support at all. Within a week, having never looked at the Clang codebase before, I had it generating code for a superset of the language that GCC supported.
I've also use clang to do syntax highlighting, to inspect files for type information for use in an FFI for a JIT-compiled language, and as a static analyser. How many tools have you seen that are based on GCC and aren't compilers?
Performance isn't the only metric by which you judge compilers, although I agree that it's an important one. OpenMP support affects a very small number of programs. Intel has just open sourced (BSDL) their OpenMP runtime and is pushing patches into clang, so that support should appear soon. The rest of the benchmarks show very little performance difference between clang 3.3 (which is in FreeBSD 10.0) and gcc 4.8, and neither is a clear winner in all cases. In comparison to the last GPLv2 GCC (4.2.1), which FreeBSD currently ships, both are significantly faster. If you need OpenMP today, gcc 4.8 is in ports, so just install the lang/gcc48 port and use it.
However, as I said, performance is not the only metric. Clang has full support for C++11 and supports more of C11 than GCC (for example, it correctly supports _Atomic and it supports _Generic). In FreeBSD, we're now using _Generic in a number of system headers and so you get better error reporting if your compiler supports them (fallback code exists if it doesn't). We found a few logic bugs in ports as a result of this, some of which have existed on other platforms and compiled without warnings for years. So, if you want to use the latest versions of C, C++, or Objective-C, clang is a better choice for you. We're also now shipping libc++ as the default C++ standard library, so we have a complete C++11 stack.
If you're developing C-family code and don't have a Coverity license, then having the clang static analyser around is also very helpful (it's built into clang, so you get it as part of the default install).
Apple doesn't directly fund FreeBSD, but they do sometimes contribute code. For example, most of the MAC framework (SEBSD) was funded by Apple and developed for both FreeBSD and OS X (the pluggable policy stuff in that makes the sandboxing for iOS and Mac App Store apps possible). When Apple wants kernel code written, they often contract work to FreeBSD devs, and are sometimes willing to fund the FreeBSD version at the same time because code that's generic enough to work on both kernels.
Lots of our downstream consumers (especially embedded systems companies) have a policy of 'no GPLv3 on the premises'. They don't want the potential liability, and they especially don't want to make it easy for them to accidentally distribute GPLv3 code. Even if they're not planning on shipping GCC in their product (and, by the way, a lot of them do ship toolchains - embedded also includes companies like NetApp and Juniper - as it makes servicing easier), there's the potential to do it accidentally if the code is sitting there on developers' machines.
As to the codebase needing auditing, we had both svn and git mirrors that allowed the entire history to be checked. We also had copies of checksums of releases and so all of these things were verified. Bringing CVS back online took a bit longer, as CVS easily let us verify the top of the tree, but not the history. I think we ended up regenerating the entire CVS history from svn, and took the opportunity to officially remove support for CVS.
Are there still vulnerabilities? Almost certainly. Any codebase more than a few dozen lines long will contain bugs, and some of them are exploitable if you're sufficiently clever. That's why a lot of the focus in 10.0 has been on mitigation techniques. The auditdistd framework lets you easily deploy auditing for an entire site. Capsicum makes it relatively easy to compartmentalise applications and a system daemons use capsicum out of the box. So do some of the normal filter utilities, for example even if you run uniq as a root user, once it's finished parsing the command line arguments it won't be able to access to any files in your system except the ones you told it to read.
They've literally deprecated fork, because they can't be bothered to make it work reliably with Core Framework
fork() deserves to be deprecated. The API originates with old machines that could have a single process in-core at a time. When you wanted to switch processes, you wrote the current process out and read the new one in. In this context, fork was the cheapest possible way of creating a new process, because you just wrote out the current process, tweaked the process control block, and continued executing. On a modern machine, it requires lots of TLB churn as you mark the entire process as copy-on-write (including TLB shootdowns which require IPIs on a multithreaded program using multiple cores). And then, in most cases, it's followed by exec() and so the process that you've just created is replaced by another one and you need to go through the whole sequence again to stop its memory being CoW.
Not only is fork() a ludicrously inefficient way of creating a process on a modern machine, it's also incredibly difficult to use correctly. When you fork(), all of your threads and all of your process descriptors are copied. You need to make sure that every thread that you create uses pthread_atfork() to ensure that it doesn't do any I/O after the fork() and before the exec(). You also need to ensure that you close any file descriptors that you don't want to be propagated to the child, which is nontrivial if you have other threads opening and closing files in the background (O_CLOEXEC helps here, but do you remember to use it everywhere?).
Oh, and posix_spawn() isn't much better. It's designed to be possible to implement on top of existing APIs and so ends up being largely useless without non-standard additions. It doesn't, for example, provide a mechanism to say 'close all file descriptors in the child, except for these ones'.
Sounds like the Brave New World solution is required. Stop demonising drugs, and make freely available drugs that give a sense of euphoria and lethargy. If people don't want to do anything with their lives other than take drugs, then let them get on with it in a non-destructive (to people other than themselves) way and remove themselves painlessly from the gene pool.
2: Flash will always be 10x cost of harddrives. In other words, Flash won't overtake harddrives on price.
That's assuming that hard drives keep getting bigger and cheaper. The amount of R&D money required for each generation of improvement (in most technology) goes up, but the spending for HDDs has gone down as manufacturers see that they're hitting diminishing returns. The number of people who will pay for 4TB disks is lower than the number that will pay for 2TB, which is lower than the number that will pay for 1TB disks and so on. For a lot of users, even 500GB is more than they will need for the lifetime of a disk.
The minimum costs for an SSD are lower than the minimum costs for an HDD. Currently, the smallest disks I can find are about 300GB, and they cost about as much as a 64GB SSD. If you bring an 8TB disk to market now, you're betting that enough people will buy it at a premium price to recoup your R&D expenses before SSDs (Flash or some other technology) pass it in capacity. But now, a lot of the people who traditionally bought the high-end disks are buying SSDs and they're caring more about latency and throughput than capacity. If you show an insanely expensive disk that gives 10x the capacity of the current best, most of these people will say 'meh,' but if you show them a disk that can do 10x the IOPS then they'll ask how much and how soon you can deliver. This gives a big incentive to concentrate R&D spending on SSDs.
It's not unproductive. There are lots of advantages of SSDs over HDDs, and only one advantage of HDDs over SSDs: price per unit capacity. Saying that comparing price per GB doesn't add anything to the conversation is like saying that comparing IOPS doesn't add anything to the conversation. If you remove price comparisons, then there is no reason to think about HDDs at all. The only reason that I have any HDDs today is that SSDs of a similar capacity are not cost effective. Price per GB is the reason that my laptop uses an SSD, but my NAS uses three HDDs: the SSD for my laptop added about 10% to the price, doing the same for my NAS would have added over 1000% to the price. If SSDs were within a factor of 2 of the price of HDDs, I'd have bought SSDs instead.
A lot of people have nuclear-powered vacuum cleaners, they just have a really long wire between the motor and the reactor...
Thank you for all of your posts in this thread. I've enjoyed a lot of Timothy Zahn books, but you've done a very good job of convincing me not to put any money into this.
I bought FTL when it was discounted on GOG. Horribly addictive. Don't start playing it if you have anything important to do over the next few days. It's amazingly simple in design - probably the highest ratio of player enjoyment to developer time of any game I've played in years.
Depends on their market segment. Apple already has the infrastructure in place for shipping fat binaries (sorry, 'universal binaries'). If they can persuade developers to ship x86-64 and ARMv8 fat binaries then a MacBook Air with a quad ARMv8 SoC and a touchscreen (and the ability to run iOS and OS X apps) might be a very interesting device. It would be seriously underpowered in comparison to the MacBook Pro, but the current MacBook Air is anyway.
Between x86-32 and ARMv7, these are all the same (well, the cost of unaligned loads and stores is more on ARM). Between x86-64 and ARMv8, they are the same. This also means that you can trivially share memory-mapped data between the two. If you were to ship a laptop with some ARMv8 cores and some x86-64 cores on cache-coherent memory interface, then you could trivially translate system calls made on the ARM chip into system calls delivered to the x86-64 operating system - you'd need to tweak the call frame, but any of the data passed by pointer would be readable by the kernel (actually, this doesn't necessarily require cache coherency, as the OS X kernel always explicitly copies data in and out via some well-defined code paths). You could also use shared memory and Mach ports to communicate between the application and the window server.
In fact, given the comparatively stateless nature of the OS X window server, it would be conceivable to have the ability to dynamically switch between a window server running on the ARM core (when in low-power mode, checking email or whatever) or the x86 core (when doing real work).
That depends a lot on what you want to work on. For some things, there are a very few institutions that specialise in a particular field, and if the reason you picked your undergraduate university was that they're world leaders in something you're interested in then you'd be crazy to go elsewhere. Similarly, if you're already at a top university then there often aren't many places where you can go that aren't a step down or don't require relocating to a different country (which may or may not be desirable).
Even if your good students do go elsewhere, if you encourage them to do a PhD somewhere then they're likely to come into contact with good undergrads at their new institution, and when those students are considering somewhere to go then you want your former undergrads to put you in touch with them.
A debug build of LLVM generates over 2GB for the debug info. Much of this is removed by the linker. For FreeBSD, it's the userland for 6 architectures when I'm doing a test build and a few dozen kernel configs. It adds up quickly.
That's true to a degree, but teaching and research (and publications) are not as separate as you might see. If you're a lecturer, a lot of your publications are going to be things that you've coauthored with your PhD or MPhil students. And the easiest way to get PhD students is to encourage your undergraduates to apply to continue studying with you (or apply for postgraduate research assistant jobs). The undergrad teaching is how you get the PhD students, and they're how you get significant quantities of research done.
Uh, what? Compiling is so fast on an existing, consumer-grade laptop with an SSD that for incremental builds it's a productivity boost, and it works when I'm at home, at work, on the train, or whatever. The difference in price between the SSD and a mechanical disk was about £300, two years ago (for a 256GB disk). It's now even lower. When I'm doing a lot of builds in different configurations I'll use a centralised server. When I'm actually hacking, I want my working copy to be local. The entire point is to speed up the edit-compile-test cycle, and sticking a network in the middle does not do that.
I have a build machine that has 24 cores, 256GB of RAM, 256GB of SSD, and 4TB of spinning rust. Building on the SSD is significantly faster than the spinning rust (factor of 2-4 depending on what you're building). Building on the RAM disk is probably 1-2% faster, but within the noise for subsequent runs. I often put the object files on the RAM disk though. It doesn't seem to impact performance, but it means that the OS never has to bother writing them out to disk, which should help the SSD last longer when I'm generating 2-30GB of object files per build.
I do, and so does everyone else on my corridor. Yes, we also have machines in racks that can build things faster, but with a quad-core i7 and an SSD in my laptop, I can build the LLVM codebase in 5-10 minutes, with incremental builds often taking under a minute, and that's a big win for my productivity over spinning rust. Most software projects that I work on have been ongoing for 10 or more years and in that time even a small team can produce something that has thousands of source files.
If you're compiling a single file, not doing a parallel build, and having all of the headers already in cache, then you'll probably see about that kind of speedup. If, however, since this isn't the 1960s anymore, you're working on a codebase with a few hundreds or thousands of files, doing a parallel build, then you'll likely see your builds take about half as long. Less if you have a faster processor, because they're now going to be totally CPU limited and not I/O bound.