81–90 of 284 posts
Also:
Do not run not your own code, like eg. JavaScript.
There is way too much short living code.
Why we not build software libraries as we learn using computers and then use it for the rest our life ?
Programmers should switch to programming human domain problems, not constantly reimplementing Start Menu hierarchy.
Btw. anybody uses Tripwire ? Eg. with apt-get or pacman and saving hashes to ro device ? ;)
A wee bit offtopic, but if we look at the VW/dieselgate, and the aftermath of it all, and the class-actions, returns, refunds, etc, and hyundai/kia lies about gas milage and people getting refunds for gas... ...when is something like this going to happen to intel? We've bought CPUs with excpectations of promised performance (like people did with emission expectations and gas milage expectations), they messed up, and…
Isn't the reason that technically the CPU is still fast and it is the OS (that is outside Intel's control) that slows it down? And AFAIK all OSes can disable these mitigations (are they even a concern for personal computers, especially for cases like gaming?) so if you really want you can get your performance back.
That's the same as buying a car from CarCompany(TM) with an A/C and a Android Car touchscreen interface/radio/..., and an automatic android updates disables your A/C and changes the engine paramters so you have 20hp less... wouln't you expect "them" to fix it? As a consumer, you shouldn't have to worry if it's googles fault or CarCompanies(TM) fault, you should be able to take it to the dealer and have them fix it or give you a refund, or atleat 'do something'?
Why aren’t the *BSD operating systems more popular in the server and workstation spaces?
...this can be a show stopper
Why aren’t the *BSD operating systems more popular in the server and workstation spaces?
There are many reasons Linux-based systems are generally much more popular than the BSDs in the server and workstation spaces. Here's why I think that happened:
* GPL vs. BSD license. Repeatedly someone in the BSD community had the bright idea of creating a proprietary OS based on a BSD. All their work was then not shared with the OSS BSD community, and the hires removed expertise from the OSS BSD community. In contrast, the GPL forced the Linux kernel and GNU tool improvements to stay in the community, so every company that participated improved the Linux kernel and GNU tools instead of making their development stagnate. This enabled the Linux kernel in particular to rocket past the BSDs in terms of capabilities.
* Bazaar vs. Cathedral. The BSDs had a small group who tried to build things elegantly (cathedral), mostly in "one big tree". GNU + Linux were far more decentralized (bazaar), leading to faster development. That especially applies to the Linux kernel; many GNU tools are more cathedral-like in their development (though not to the extent of the BSDs), and they've paid a price in slower development because of it.
* Multi-boot Installation ease. For many years Linux was much easier to install than the BSDs on standard x86 hardware. Linux used the standard MBR partitioning scheme, while the BSDs required their own scheme that made it extremely difficult to run a BSD multi-boot setup. For many people computers (including storage) were very expensive - it was much easier to try out Linux (where you could dual-boot) than BSDs. The BSDs required an "all-in" commitment that immediately caused many people to ignore them. I think this factor is underappreciated.
* GNU and Linux emphasis on functionality and ease-of-use instead of tiny-ness. GNU tools revel in all sorts of options (case in point: cat has numerous options) and long-name options (which are much easier to read). The BSDs are often excited about how small their code is and how few flags their command lines have... but it turns out many users want functionality. If tiny-ness is truly your goal, then busybox was generally better once that became available circa 1996 (because it focused specifically on tiny-ness instead of trying to be a compromise between functionality and tiny-ness).
Some claim that the AT&T lawsuit hurt the BSDs, but there was lawsuit-rattling for Linux and GNU as well, so while others will point to that I don't think that was serious factor.
Here's one article discussing this:
https://www.channelfutures.com/open-source/open-source-histo...
Earlier quoted context omitted.
Because sane defaults are important.
Isn't this a "sane" default only in specific contexts though? (VMs). For a desktop PC that almost always runs a single heavy task (games, rendering, video encoding, etc) hyperthreading can be a day and night difference.
Earlier quoted context omitted.
Because sane defaults are important.
Isn't this a "sane" default only in specific contexts though? (VMs). For a desktop PC that almost always runs a single heavy task (games, rendering, video encoding, etc) hyperthreading can be a day and night difference.
If the desktop PC has wrong default the performance is bad. Still functional though.
If in case of VM the default is wrong we will read another headline about how N million customers of $company got their personal data leaked.
Earlier quoted context omitted.
10 years? Of course not. But if i bought it yesterday, I'd expect a refund. Just consider that they were still selling affected CPUs even when they knew about the vulnerabilities and even after the papers were published.
> Of course not. But if i bought it yesterday, I'd expect a refund. If you bought it yesterday, why wouldn't you be able to get a refund? I don't know of any major vendor that would deny you a refund on grounds that the unit is defective.
Earlier quoted context omitted.
> setting it up to be conservative just like OpenBSD Meh. Probably for superficial stuff, yes. But would Linux kill cat(1) if it did some network calls? I bet not. See https://www.openbsd.org/innovations.html
You could block it's network access with network namespaces: http://man7.org/linux/man-pages/man1/unshare.1.html I'm sure you could engineering something to kill it also with currently kernel functionality - though I would need to do more research to say what.
A wee bit offtopic, but if we look at the VW/dieselgate, and the aftermath of it all, and the class-actions, returns, refunds, etc, and hyundai/kia lies about gas milage and people getting refunds for gas... ...when is something like this going to happen to intel? We've bought CPUs with excpectations of promised performance (like people did with emission expectations and gas milage expectations), they messed up, and…
History will show that Theo was right in a manner similar to how Stalman was right: technically correct analysis and eerily accurate predictions, but lacking in sufficient charisma to create more than a small following. To some extent, you might say they are like Cassandra; speaking the truth but not believed or listened to.