Forgot your password?
typodupeerror

Comment: Anti-Spam Measure? (Score 3, Insightful) 245

by ewhac (#48365367) Attached to: ISPs Removing Their Customers' Email Encryption
Didn't this very topic come up a few days ago? I recall the general consensus being that it's an anti-spam measure, and (is supposed to) only happen when connecting on port 25 to a non-local machine (port 25 is supposed to be for server-server communication only). Normal clients are supposed to be able to avoid the issue by changing your MUA to submit mail on port 465 (smtps) or 587 (smtp). I suspect people running their own SMTP servers will probably need to negotiate with their ISPs, or relay their mail through their ISP's SMTP server as a smarthost.

Comment: Thanks to Everyone! (Score 1) 928

by ewhac (#48286095) Attached to: Ask Slashdot: Can You Say Something Nice About Systemd?

Well... All told, I think that went rather well.

I wanted to chime in and thank everyone for participating in what was clearly an insane exercise in trying to cut through the acrimony and vitriol and get some actual information on what systemd is and what it's trying to do. You can't always grok what complex things are about just from the docs. That's why I wanted actual first-hand experiences from people who could point to actual gems they'd found.

To respond to some recurring remarks throughout the comments:

  • "Obviously a pro-systemd shill."
    No, I'm not shilling for RedHat or Poettering. In fact, I gave Poettering some stick for the whole corrupt-binary-logs-aren't-a-bug thing a couple weeks ago. I was being forthright in the opening paragraph: The simple fact that systemd has been widely adopted despite widespread protest made me genuinely wonder what I was missing that I hadn't figured out from the docs I'd read. So, no, there's no conspiracy here.
  • "Who are you to establish posting rules?"
    Well, gosh, sorry, but I was trying to save everyone time. Seriously, tell me you haven't gone, "Oh, ${DEITY}, another systemd thread; there goes my afternoon as I pick through the rat's nest of comments." So I hoped -- perhaps naively -- that requesting some organization would let us all get to the meat of issues of interest fairly quickly. And enough people did choose the follow the rules that the discussion overall turned out valuable (for me, anyway).
  • "Why do you dislike something you admit you know nothing about?"
    For largely the same reason I dislike Windows without having comprehensively pored over the "design" docs for COM, DCOM, MFC/ATL/WTL, WDM, NTFS, NTLM, Direct${THING}, Active${THING}, etc. etc. etc. Poorly-designed systems seem to have a certain "pattern" to them, and systemd at first glance seemed to match that pattern (the use of Windows-style INI files syntax didn't help, either). But the people adopting systemd are clearly not idiots, so I hoped people with actual experience with the thing could convey insights that (for me) the docs so far have not.
  • "You're thinking of the ads for Miller Lite, not Bud Light."
    *headdesk* I would like to apologize to a no doubt deeply irritated TV ad executive for completely misattributing their fifteen-odd years and millions of dollars worth of loud beer ads to the wrong company (I think this speaks well to my socially-isolated geek cred, though :-) ).

In the best tradition of USENET, I thought I'd summarize the highlights of what I got out of the whole thing. Most of the good posts have already been modded up, but the ones that especially stood out for me were these:

Thanks again to everyone who chimed in. You've given me a lot to read up on...

Comment: Re:It freakin' works fine (Score 1) 928

by ewhac (#48285843) Attached to: Ask Slashdot: Can You Say Something Nice About Systemd?

Think back to the epic holy wars of the past. Emacs vs. Vi. Big vs. Little Endian. Motorola vs. Intel. Amiga vs. Atari ST. ASCII vs. EDBIC.

vi*. Little-endian. Motorola. Amiga. ASCII**. Obviously.

(* with great respect to those who are able to use EMACS well.)

(** Seriously, who not using punched cards ever actually liked EBCDIC?)

+ - Say Something Nice About systemd 4

Submitted by ewhac
ewhac (5844) writes "I'm probably going to deeply deeply regret this, but every time a story appears here mentioning systemd, a 700-comment thread of back-and-forth bickering breaks out which is about as informative as an old Bud Light commercial, and I don't really learn anything new about the subject. My gut reaction to systemd is (currently) a negative one, and it's very easy to find screeds decrying systemd on the net. However, said screeds haven't been enough to prevent its adoption by several distros, which leads me to suspect that maybe there's something worthwhile there that I haven't discovered yet. So I thought it might be instructive to turn the question around and ask the membership about what makes systemd good. However, before you stab at the "Post" button, there are some rules...

Bias Disclosure: I currently dislike systemd because — without diving very deeply into the documentation, mind — it looks and feels like a poorly-described, gigantic mess I know nothing about that seeks to replace other poorly-described, smaller messes which I know a little bit about. So you will be arguing in that environment.

Nice Things About systemd Rules:
  1. Post each new Nice Thing as a new post, not as a reply to another post. This will let visitors skim the base level of comments for things that interest them, rather than have to dive through a fractally expanding tree of comments looking for things to support/oppose. It will also make it easier to follow the next rule:
  2. Avoid duplication; read the entire base-level of comments before adding a new Nice Thing. Someone may already have mentioned your Nice Thing. Add your support/opposition to that Nice Thing there, rather than as a new post.
  3. Only one concrete Nice Thing about systemd per base-level post. Keep the post focused on a single Nice Thing systemd does. If you know of multiple distinct things, write multiple distinct posts.
  4. Describe the Nice Thing in some detail. Don't assume, for example, that merely saying "Supports Linux cgroups" will be immediately persuasive.
  5. Describe how the Nice Thing is better than existing, less controversial solutions. systemd is allegedly better at some things than sysvinit or upstart or inetd. Why? Why is the Nice Thing possible in systemd, and impossible (or extremely difficult) with anything else? (In some cases, the Nice Thing will be a completely new thing that's never existed before; describe why it's good thing.)

Bonus points are awarded for:

  • Personal Experience. "I actually did this," counts for way more than, "The docs claim you can do this."
  • Working Examples. Corollary to the above — if you did a Nice Thing with systemd, consider also posting the code/script/service file you wrote to accomplish it.
  • Links to Supporting Documentation. If you leveraged a Nice Thing, furnish a link to the docs you used that describe the Nice Thing and its usage.

We will assume out of the gate that systemd boots your system faster than ${SOMETHING_ELSE}, so no points for bringing that up."

Comment: Re:Congratulations, FTDI, You Just Killed Yourselv (Score 1) 700

by ewhac (#48207355) Attached to: FTDI Reportedly Bricking Devices Using Competitors' Chips.

The chips are not destroyed.

Yes, the bricked chips can (allegedly) be restored to working order through the use of a utility. "Hang on. Would this utility be furnished by the very same company that wrecked my device in the first place?" Why yes; is that relevant? "Very fscking hilarious; I'll be looking elsewhere for my USB-serial adapter needs from now on..."

This is a distinction without a difference, as they say. You wouldn't cut any slack to a malware author who tried to claim, "Oh, the files aren't destroyed. They're merely encrypted, and can be restored to their previous condition through the use of this handy-dandy decryption key, available exclusively from me... for a modest fee..."

Comment: Congratulations, FTDI, You Just Killed Yourselves (Score 4, Insightful) 700

by ewhac (#48206865) Attached to: FTDI Reportedly Bricking Devices Using Competitors' Chips.
Assuming FTDI manages to weasel out of lawsuits for willful destruction of property (do NOT let them hide behind the so-called EULA), they have basically made themselves the vendor to avoid for either chips or drivers for said chips.

Can you tell, by merely looking at it, whether a given device is using GenuineFTDI(TM)(R)(C)(BFD) chips, or whether it's a counterfeit? Can you tell by using whatever the Windows equivalent of lsusb is? No? Then there is a random, non-trivial chance that plugging in your serial-ish device will either:

  • Work (old non-destructive drivers),
  • Not work (new, non-destructive drivers),
  • Ruin the device (new, destructive drivers), so that it not only Not Works, but also Stops Working on every other machine on which it previously worked.
  • Thus, in the mind of the user, FTDI == Flaky. And Flaky == Avoid.

    Congratulations, FTDI. Ten points for avoiding your feet, but minus several million for shooting yourself straight in the head.

Comment: Re:New Object (Score 1) 70

by rjh (#48206649) Attached to: Astronomers Find Brightest Pulsar Ever Observed

A neutron star is a gravitationally-bound sphere of neutrons, not plasma, and yet it's still a star.

I would respectfully suggest that a good definition of a star would be, "a gravitationally bound collection of energetic matter engaged in largely Brownian motion." That covers everything from brown dwarfs (D-D fusion requiring substantial energy to initiate) up to hypergiants and neutron stars. (Even a cold, dead neutron star possesses enough energy to dramatically warp spacetime -- there's a lot of energy there to be tapped.)

This definition would also exclude black holes, as a singularity isn't really "matter" per se -- matter requires volume, and a singularity has none of that.

It would also exclude galaxies and accretion discs, as those are not engaged in Brownian motion.

Comment: Re:Sound waves as quantum particles? (Score 2) 66

by rjh (#48132861) Attached to: Hawking Radiation Mimicked In the Lab

You can thank wave-particle duality. In the quantum world, if something has an existence as a wave, it must also have an existence as a particle. Sound waves have a particle analogue: phonons.

Also remember: in quantum mechanics there's no such thing as a vacuum. Virtual particles spring into existence constantly, making it possible to interact with vacuum in a number of really surprising ways.

Comment: This Is Lennart's Defense? (Score 4, Insightful) 774

by ewhac (#48097261) Attached to: Systemd Adding Its Own Console To Linux Systems
Every time the systemd thing comes up, I want to hate it, but I don't truly know enough about it to actually hold a defensible opinion.

One of the defects constantly levelled against systemd is its propensity to corrupt its own system logs, and how the official response to this defect is to ignore it. The uselessd page has a link to the bug report in question, which was reported in May 2013 and, over a year later closed and marked NOTABUG. However, it seems Mr. Poettering is getting annoyed by people using his own bug reports against him, and added a comment to the bug report today purporting to clarify his position.

Unfortunately, his "clarifications" serve only to reinforce my suspicion that systemd is a thing to be avoided. To wit:

Since this bugyilla [sic] report is apparently sometimes linked these days as an example how we wouldn't fix a major bug in systemd:

Well, yeah, corrupt logs would be regarded by many as a major bug...

...Now, our strategy to rotate-on-corruption is the safest thing we can do, as we make sure that the internal corruption is frozen in time, and not attempted to be "fixed" by a tool, that might end up making things worse. After all, in the case the often-run writing code really fucks something up, then it is not necessarily a good idea to try to make it better by running a tool on it that tries to fix it up again, a tool that is necessarily a lot more complex, and also less tested.

Okay, so freeze the corrupted data set so things don't get worse, and start a new data set. A reasonable defensive practice. You still haven't addressed how the corruption happened, or how to fix it.

Now, of course, having corrupted files isn't great, and we should make sure the files even when corrupted stay as accessible as possible. Hence: the code that reads the journal files is actually written in a way that tries to make the best of corrupted files, and tries to read of them as much as possible, with the the subset of the file that is still valid. We do this implicitly on every access.

Okay, so journalctl tries to be robust, assumes the journal data might be crap, and works around it. So we can assume journalctl is probably pretty solid and won't make things worse.

Hence: journalctl implicitly does on read what a theoretical journal file fsck tool would do, but without actually making this persistent. This logic also has a major benefit: as our reader gets better and learns to deal with more types of corruptions you immediately benefit of it, even for old files!

....Uhhhhh-huh. So, yeah, newer tools will do a better job of working around the corruption, and we'll be able to recover more data, assuming we kept known-corrupt logs around. But what I still don't understand is WHY THE LOGS ARE CORRUPT. And why aren't there log diagnostic and analysis tools? If you already know your logs can turn to crap, surely there are structure analysis tools around that let you pick through the debris and recover data that your automated heuristics can't.

And why do I get the feeling that implied in the above is, "You don't need to know the log structure or how to repair it. We'll write the tools for that. We'll release better tools when we get around to it?"

File systems such as ext4 have an fsck tool since they don't have the luxury to just rotate the fs away and fix the structure on read: they have to use the same file system for all future writes, and they thus need to try hard to make the existing data workable again.

....AAAAnd you lost me. Seriously, this is your defense: "Filesystems are more important than system logs, so they have to try harder?" I find this insinuation... surprising. You do realize that btrfs didn't become worthy of general use overnight, right? (Some might argue it still hasn't.) It took years of development, and hundreds of people risking corrupt or destroyed filesystems before the kinks got worked out, and the risk of lost or corrupt files approached zero. More significantly, during this long development time, no one ever once suggested making btrfs the default filesystem for Linux. People knew btrfs could ruin their shit. No one ever suggested, "Oh, well, keep a copy of the corrupt block image and format a new one; we'll release better read tools Real Soon Now." No one suggested putting btrfs into everyday use until it proved its reliability.

Likewise, until it can demonstrate to the same level of reliability as common filesystems that it doesn't trash data, systemd is experimental -- an interesting experiment with interesting ideas and some promise, but still an experiment. I would appreciate it if you didn't experiment on my machines, thankyouverynice.

I hope this explains the rationale here a bit more.

No, sir. No it does not.

P.S: Is there any evidence to suggest that systemd log corruption issues have since been solved?

Comment: Re:HP (Score 1) 118

by ewhac (#48075339) Attached to: HP Is Planning To Split Into Two Separate Businesses, Sources Say

- the Windows 8 era machines include Windows 7 AND 8 installation disks - choose whatever you like.

If you custom-build a machine from their ZBook "Mobile Workstation" line, you can even configure a machine to not have Windows installed at all. Saves you about $100.00. Still rather pricey, though...

Comment: Re:ARE YOU LIKE STUPID???? (Score 1) 577

by ewhac (#48042889) Attached to: Will Windows 10 Finally Address OS Decay?

1) fix the PAGEFILE. Go inot the settings and change ti to fixed size - 2x-3x size of ram - both of minimum and maximum size. Do not let WInodws manage it! [ ... ]

Better still, move PAGEFILE.SYS off of C: entirely, preferably on to its own spindle if you can. That way the swapper isn't having a fight with every other application in the system for accessing system files; and PAGEFILE.SYS itself won't become fragmented.

Consider moving %TEMP% and %TMP% off of C: as well.

4) Dump the System Restore from time to time. This is just junk removal. [ ... ]

Sadly, this appears to be an all-or-nothing affair -- on XP, you can either delete all restore points or none of them. It would be nice to delete those that are, say, more than a year old.

Comment: My story with Epic (Score 1) 240

by rjh (#48041475) Attached to: Back To Faxes: Doctors Can't Exchange Digital Medical Records

Some years ago after being laid off from one programming job, my old CS prof from college suggested I stop by to interview with the Epic recruiter who was visiting the campus. I was told to block out about four hours time, and that it would be a very in-depth technical interview. It turned out to be nothing of the sort: it was maybe ten minutes of talk with a human being, and hours and hours of filling out a badly-written "technical exam". Allegedly it involved seeing how well the taker could think about programming languages and programming language concepts by giving us a toy language to write a parser and compiler for, but ... holy toledo, was it a stinker.

First, the language was defined in plain English. There was no BNF. When ambiguities of English occurred (as they always do), the Epic rep was unable to give any resolution as to what the language was supposed to do. My protest of, "Well, if you don't know what it's supposed to do, how can you expect me to write a parser or compiler for it?" fell on deaf ears.

Second, certain mathematical operations were supposed to be supported ... but the language was vague: they were supposed to have their "conventional" meanings. But some mathematical operators are defined sort of vaguely: for instance, it's not really well-defined mathematically what the modulo of two negative numbers are. As a result, different programming languages tend to implement it differently. (For instance, C++03 says it's implementation-dependent, while C++11 has a strict policy on it.) How did they want the modulus operator implemented? They had no idea.

Ultimately, when it came to writing a parser and compiler for their toy language I decided to do it the right way as opposed to their way. Instead of having an ad-hoc thing, I turned the exam over and started writing a formal BNF and lex/yacc rules on the back of the pages. I took the full four hours to do the technical exam, turned it in, told them that my work was on the *back* of the exam and not the front, and walked out.

Six weeks later, not having heard a thing from Epic, I sent them a politely-worded email saying, "If I'm going to spend four hours on a Saturday on an interview for Epic, I would appreciate the courtesy of being told whether I would be receiving a job offer or not."

A week after that I received a one-line email: "We regret to say that we're going with other candidates."

Anyway. That's my experience with Epic. Take it for whatever it's worth. I didn't think much of their interview process, and they sure didn't think much of me.

FORTRAN is a good example of a language which is easier to parse using ad hoc techniques. -- D. Gries [What's good about it? Ed.]

Working...