wsfull

That's not nice and totally uncalled for. Three years is a very short time.

The original comment did not compare xbps to BSD package managers. What it said was that xbps was written by a former NetBSD developer and thus arguably has different qualities than other Linux package managers. It is a different approach from someone with different sensibilities than a Linux developer. I have read comments from Void Linux mantainers and users that say more or less the same thing.

Why are you comparing pkgsrc to pacman. The orginal comparison suggested in the parent comment was between xbps and nixpkgs or other Linux package managers.

pkgsrc boostraps itself using a program called "boostrap" in the pkgsrc directory. It builds a version of NetBSD's GCC toolchain and has no reliance on the host's userland. IME, this is very reliable and is its single greatest strength. Beyond that, pkgsrc is only as good as the build processes chosen by the author(s) of the software being built. These of course vary widely in sanity and depending on the packages one is building the otherwsise sane pkgsrc build process can quickly become a black box with packages that pull in many dependencies. It does break sometimes, but this is a fault of the target software authors, not pkgsrc. pkgsrc is first and foremost a system for building packages. Linux distributions OTOH tend to be much more focused on binary package managers. Most Linux users do not build packages from source. There is really no comparison.

Your comments do not sound like those of a daily NetBSD user. I have been one for the last 15 years and am therefore all too familiar /usr/share/mk. Most Linux users do not seem very comfortable with BSD makefiles.

Care to be more specific than "underlying stuff". The code and design of xbps looks nothing like the code or design of pacman or apk.

If the cost to students attending universities that have adequate subscriptions is small -- previously, commenters suggested this portion of their tuition amounted to only a small annual fee -- then what would be the reasons the publishers would not offer individual subscriptions at similar cost to the public? As any serious student knows, the "a la carte" prices are absurd -- how successful have they been with this idea?

One silly idea deserves another:

Generally, journals manage their subscriptions through filtering on IP address ranges.

Imagine a customer-ISP agreement that had an option whereby a subscriber could "opt in" to academic journals for a few extra dollars per month.

These subscribers might then be assigned addresses in certain designated ranges by their ISP.

Yes.

As yet, there's still no foolproof way to verify/authenticate an endpoint on the internet. Not to mention the issue of so-called "host security".

Checking for a file on the remote host, e.g., a cert or a key a la ssh, seems to me a more sensible approach than relying solely on the promises of a "trusted third party" (CA's, ICANN, registrars, etc.) that you have never met.

Fears of ISP's intercepting port 53 traffic was not the reason why DNSSEC was revived from the failed protocol graveyard. ISP's do not have to go through the trouble. Most of their customers have the ISP's resolver addresses in their DNS settings, not a loopback address.

And although the software is available almost no ISP customers are encrypting their DNS packets.

DNS data for the public www is public information like the telephone book. It is easy to obtain. And once you have it, not only can you monitor changes, but there's little need to even run a cache.

You can just pluck out the names you need and plug them into your own authoritative server. Edit resolv.conf to point to it and you're done.

Easy way to speed up your www browsing and still very effective at blocking ads, apps phoning home, etc.

If you are using your own DNS cache listening on a loopback interface, then the risks of "DNS cache poisoning" are not what they are when you use a third party cache like your ISP's, OpenDNS, Google or the ones in the CSV file at the github page referenced in this blog entry.

Unless you are sharing your loopback with the network somehow, one could argue that with a localhost cache the risk is nonexistent.

According to this blog entry the reason for using DNSSEC is to "prevent DNS posioning".

If that is true, and that is what I would expect, and we've minimized the risk of cache poisoning by using a localhost cache exlcusively (no third party caches), then why use DNSSEC?

If there are other reasons, like making centralized control (censorship?) of DNS easier for ICANN, etc., then this blog post has omitted them. Does that imply they are insignificant?

If you got a free 32-bit version while while the terms were "shockingly liberal" then maybe those are the terms that govern the use of that binary? I don't know for sure.

I do know in addition to changing the license they have made changes to the software since that time. The size of the binary has increased.

I worry more about Kx being acquired by some large company, maybe a competing database vendor, that cares little about software quality.

If you follow the "API war" hyperlink, it's under the heading "It's Not 1990".

When consumers are upgrading their hardware regularly as they were in the 1990's, then developers can disregard the notion of users "upgrading" their software.

Instead they can just write applications targeting new hardware. It does not have to run on older hardware.

The user will be compelled to upgrade the hardware and, in the case of Windows, by default they get the new software. The example cited was Excel versus Lotus123.

MS also benefitted from hardware sales through agreements with the OEM's.

Here's my tl;dr:

1. Interix/SUA subsystem was not developed by Microsoft. It was acquired from a company called Softway. It was used internally to transition Hotmail from FreeBSD to Windows. It is believed some important MS customers also made use of Interix and possibly came to rely on it.

2. How to explain MS seeming ambivlance toward a POSIX layer on top of Windows? Idea: Windows API is so complex (convoluted?) as to exclude competition. See Joel On Software reference. He marvels at Windows' backwards compatibility - being able to run yesterday's software on today's computers. Yet he also admits MS strategically developed software that would not run on today's hardware, but only on tomorrow's. (Not intending to single out MS as I know other large companies in the software business did this too.)

Complexity as a defensive strategy. Who would have guessed?

Many years ago, I gave up on Windows in favor of what I perceived as a more simple, volunteer-run UNIX-like OS that was better suited to networking.

As it happens, unlike Windows, _all versions_ of this OS run reliably on most older hardware. Although it was not why I switched at the time, I have come to expect that by virtue of the UNIX-like OS, my applications will now run on older as well as current hardware. I rely on this compatibility.

Unlike Windows I can run the latest version of the OS on the older hardware.

Windows backwards compatibility is no doubt worthy of praise, however the above mentioned compatibility with older hardware is more important to me than having older software run reliably on a proprietary OS that constantly requires newer hardware.

The 2004 reference Reiter cites on the "API War" suggests people buy computers based on what applications they will be able to run.

Unlike the reference, I cannot pretend to know why others buy certain computers. Personally, I buy computers based on what OS they will be able to run. Traditionally, in the days of PC's and before so-called smartphones, if you were a Windows user this was almost a non-issue. It was pre-installed everywhere.

At least with respect to so-called smartphones it appears this has begun to change. Maybe others are choosing to buy computers based on the OS the computer can run? I don't know for sure.

As for the "developers, developers, developers" and availability of applications idea, since switching to UNIX-like OS, being able to run any applications I may need has been a given. In fact, I have come to rely on applications that will only run on UNIX-like OS!

And now it seems MS is going to make running UNIX applications on Windows easier. Why?

As with Interix, will the reasoning behind this successor POSIX layer remain a mystery?

The only problem is if one uses UNIX instead of Windows to do development.

Fortunately there are still some people doing development on UNIX and sharing their software tools.

http://cr.yp.to/highspeed/fall2006.html

No, I do not think you are being negative. Assuming you are approaching HTTP/2 from the user's perspective.

Honest opinion: HTTP/2 benefits advertising companies* like Google more than it benefits users, if in fact it even benefits users at all.

Perhaps the most oft cited "benefit" to users is encryption. PHK addresses that one.

He has a nice line in there about secrecy vs privacy. It's an important distinction.

And he reminds us that Google does not care if users are more or less unable to use self-signed certs.*

*I saw a prominent Googler refer to his employer an "advertising company" as well as express his distaste for allowing users to choose to use self-signed certs (policy reasons).

Of course I'm assuming users want less advertising, not more.

In the case you are a user who wants more advertising, and you want it delivered as fast as possible, and you are not concerned about what information is being sent from your computer to the advertising companies when you use a browser... like the ones written by advertising companies or organizations that are paid by advertising companies, then please disregard my opinion.

I'm biased. I want less advertising, not more.

Plus I have been a long time HTTP/1.1 pipelining user, using a simple HTTP client. I use pipelining to download 100 or more pages of HTML or plain text at a time over a single connection, not 100 ads or other junk I do not need. All in a fraction of the time that it takes one of today's bloated www pages to load in a "modern browser".

Whatever the "benefits" to users that HTTP/2 proponents have cited, I have found they can be easily countered or dismissed.

HTTP/2 benefits advertisers, no doubt. What else would you expect when the draft spec was written by an advertising company?

It's enticing to think about the successor to HTTP/1.1 and what could be improved. But as a _user_ this version of "HTTP/2" is not what you want.

Assumption 1: the primary customers of increasingly expensive subscriptions from academic publishers are universities.

Assumption 2: the cost of the subscriptions is passed on to the primary customers of the universities -- students.

Assumption 3: assumptions 1 and 2 are correct.

Question: Is there any correlation to be made between the profitability of such academic publishers with the astounding rise in university tuition in the US over the past three decades?

I became an admirer of this man's software aesthetic when I first discovered and compiled libero.

In my opinion, this is a great loss to the world of programming.

tinysshd does not have the 90's crypto by default. It is optional. Nor does it have the "extreme complexity".

Is generating ed25519 keys slower or faster than generating self-signed certs?

Nothing wrong with OpenSSH supporting the option to use certs. They can be useful to some users.

But the entire X.509 scheme to my knowledge was based around some idea of third party verification.

This gave rise to the business of selling CA "services". Problematic to say the least.

And still to this day, "self-signing" appears to be disfavored. Or perhaps the openssl binary is just too loaded with options for users to learn the commands to generate CA and server certs and keys.

Whether it truly is or not, ostensibly "SSL/TLS certificates" to the public seems to require third party involvement.

ed25519 keys do not have this problem. And generating them is relatively fast.

Clarification: By "authentication" I mean keys that the users generate using ssh-keygen. I do not mean certificates or "certficate authorities" (CA's).

Idea: Maybe it's the "sh" in ssh that make it so useful. Environmental variables instead of "HTTP headers". envdir

Opinion: In terms of "authentication" I still think ssh has the edge over anything associated with http/https and www. Two parties should be able to authenticate to each other without involving a third.

Say what you will but I still prefer the VAX to Windows.

Generally, very little is "turned on by default" which sets this OS apart.

Where are you getting your rc.conf?

This looks reasonably conservative: 1 line.

/pub/NetBSD/NetBSD-release-6/src/etc/rc.conf:

rc_configured=NO

You forgot to mention the option of half flush or full flush.