Astrology fits the definition of careful observations, using those observations to explain other observed behavior, and making predictions. Data gathering and theories aren't science by themselves.

Now, with that trailer, you have a definiton of science. "Testable". But, apparently the TFA doesn't include testable hypotheses.

Too many flames in these weekly Wayland discussions and not enough facts (or maybe the facts are downmodded; I've gotten to the point where if I look at a wayland article, I don't read all of the comments).

So, I just spent 5 or 10 minutes skimming the Wayland FAQ and architecture diagram.

For comparison, when running X, you might have an ordinary window manager or you might have a compositing window manager. The Wayland model is that it *is* a compositor that provides both window manager functions and some of the functionality of an X server.

Intentionally misstating things rather badly, it sounds like the reason Wayland doesn't support remote displays is because it also doesn't support local displays! More accurately, wayland supports local displays (of course), but unlike X11 provides no way to render to them. Wayland doesn't do rendering; it apparently "just" knows how to swap video buffers to a display device and coordinate buffers between multiple clients.

I'm thinking that, for example, if you want to write a graphical app, you might target OpenGL or cario and then expect your code to work in both Unix (with X) and on Windows (without X). With Unix/X, I'd expect an opengl library that handed X primitives to the X server. With Wayland, you'd apparently have an opengl library that rendered to a buffer and then handed the buffer off to the Wayland compositor.

So, Wayland isn't doing some of the things we'd expect an X server to do. Wayland is never working with drawing primitives. It seems obvious that you'd never be able to run apps that use the old X toolkit libraries against Wayland without an X server in the picture. And, the FAQ admits this and notes that you'll need an X server in addition to Wayland for the foreseeable future.

However, as others have noted, an obvious question is how efficiently a "native" Wayland app could be displayed remotely. If the app and its libraries are rendering graphics primitives into display buffers, it seems obvious that low level primitive operations are lost by the time wayland gets the buffers, so you now have to be able to efficiently transmit bitmap deltas. Queue arguments re whether drawing primitives are more efficient or bitmaps are more efficient... OTOH, it seems unlikely that apps would include their own rendering code instead of using as library. So, we can hope that the libraries offer both wayland and X backends, I guess.

Not an X server developer nor a Wayland developer. I'm sure I garbled things somewhat, but perhaps someone could clarify the mistakes and help take a portion of the FUD out of the weekly Wayland discussions.

Back in the day, there were programs for MS-DOS (and no doubt other OSes) that would use "low level" access to the floppy drive in an attempt to be able to read any known type of encoding (and filesystem too of course). I recall one that supported dozens or hundreds of formats from various types of PCs and OSes (CP/M boxes, Amigas, Apples, etc). This was a couple of decades ago, so I don't recall the names of the software. I imagine a search would turn some of these up. It'll likely be "shareware" or commercial rather than open source, so if you find one, it'll probably be useful only with a good emulator or real HW and not as a reference.

At any rate, I imagine the various computer history museums have specs, S/W, and H/W and that there are few formats that are truely orphaned.

Todays specs and formats are no doubt even less likely to be lost at it's more common to have computer copies of these and even to publish them than it was in 80's and earlier.

OTOH, as others have noted, the shelf life of some of the older media is getting long in the tooth. I've got a 9-track tape from college that's probably unreadable. (And probably of little interest anyway).

Fourteen digits are given by a mnemonic I learned in grade school:

Just count the letters in each word.

Decades ago, when the first bank ATMs were being marketed, bank managers were skeptical. They thought that customers preferred human tellers and thought that "people are not going to walk up to a machine and use it".

The fact that people often prefer automated systems is *not* evidence that people don't like talking to or interacting with other people. It's evidence that people would rather deal with a robot than deal with a human in a stylized, scripted, robotic interaction. Efficiency, lack of fuss, predictablity, just getting it done, etc FTW!

So, yeah. Automation threatens some roles previously done by humans. Editor as troll?

tl;dr It's often preferable to interact with real automation than humans playing robots.

Well, 110 baud is 110 bits-per-second. If that's not a unit of measure that involves the binary system, ... But yeah, the quantities aren't powers of two.

The earliest VM subsystem that I've looked at is the one for Multics in the 80's. What early systems had VM pages that were not multiples of disk sector size? Just curious.

That's not pre-crime. It's crime. Having child porn doesn't just mean the viewer might abuse a child in the future. It also means a child was abused to create the images.

There *is* something magical about a 512 byte or 4096 byte sector size.

It may be possible for a hard disk sector size to be 520 bytes, but it's not convenient nor efficient. What computers do with hard disks at the most basic level is to transfer data between memory and disk. Since computers are binary, it only makes sense that the size of "pages" of memory used in virtual memory schemes be a power of two. It's also much simpler and saner if these in-memory pages are a multiple of the sector size.

Similarly, the nature of digital signaling explains why early networking speeds involved powers of two.

You're arguing that a phone is not a physical object because it can be used to communicate data. By that logic, the RSA secure-id hardware token I have is also not a second facter and would just be a different mechanism to give me auth data that I type into my work's VPN SW in addition to my password. That's bad logic. You're confusing the question of whether or not a phone is an object that may be physically possessed with how that object is used.

As noted at two factor authentication, the three types of factors are knowledge (something you know), possession (something you have), and something you are.

The typical example of "something you know" is, of course, a password.

Both a phone and a physical key are objects. Things you might have. Neither is knowledge. A door key may be used to move tumblers while the phone is used to receive secrets to be echoed back. Note that you're receiving a new secret that you didn't previously *know*. This is quite different than, for example, simply typing in your phone number.

Nor is whether or not something is a physical posession or whether its knowledge related to whether or not it can be compromised. A physical key can be duplicated; a phone can be cloned; either can be stolen. Nor would we bother with using more than one factor if it wasn't possible that factors could be compromised.

However, some attack vectors work by using one type of factor in place of another. For example, say you get the serial number of my hardware token, acquire the algorithm the tokens use to generate changing numbers, and any necessary initial conditions. Some might argue that you're using knowledge to subvert a mechanism designed to require use of a unique physical object. Calling it a virtual duplicate might be more accurate. Still, my physical token remains a physical object; it doesn't disappear in a puff of logic just because you found a way to trick the system is to thinking you had something you don't have.

That's not just close; it *is* two factor. You have the phone. Well, maybe some guy who took it at gunpoint has it, but it's still a different factor (have) than the password (know).

Yeah, the ability to disable the mailing of numbers by flagging the computer as trusted arguably *does* remove the 2nd factor. However, I imagine that that bank feels that browser or IP fingerprinting still yields a "something you have".

I'm not sure that they're even saying JS is preferred. (Not sure that they aren't because I just skimmed the blog.) However, the whole context might be

Only using a single language in noob/intro examples isn't quite the same thing as deprecating other languages...

From the TFA and the blog linked from the TFA:

Why only one?

But also:

I wonder how much harder it would be to support LUA, python, tcl, and some of the other common languages. Or whatever comes next...

Good grief. I was on U-Verse briefly in 2008 or 2009 in Houston. We had an outage that IIRC lasted a few days. I don't recall the exact details, but I think it was some sort of DHCP server issue. In addition to apparently not having an architecture that where possible limits the scope of issues to something less than multiple states, it sounds like they haven't even learned from past problems.

The folks over at gog.com (once called Good Old Games) also proved that people will pay reasonable prices for old stuff. However, not unsurprisingly, when they first started gog.com, it was apparently a struggle to get vendors to agree to sell DRM-free versions of their out-of-print games.

How much of your own effort do you want to put into it? It's easy to put your own cheap off the shelf router just before the ISP's device and flash it with your own firmware. Look at OpenWRT or one of the other FOSS or commercial firmware router projects. Probably pretty common among /.ers. Since they provide statistics via SNMP, a (free) off-router network monitoring package could provide all sorts of usage graphs. Admittedly, many of these only show past day/week/30 days and not usage since the first of the month. There are a raft of reasons why it's a good idea to deploy one of these, including improved security. Using bandwidth monitoring and iptables to do custom throttling would be feasible, but you might have to build it.