Forgot your password?

Comment: a solution in search of a problem (Score 1) 75

by Simonetta (#47855337) Attached to: Book Review: Architecting the Cloud

Until such time that the tech community of the world can and will effectively deal with (i.e. either convince to stop misbehaving or just kill 'em) all the brilliant psychopathic programmers in their mist that create malware and viruses that defraud millions of people, then it is plain madness and criminal negligence to encourage people to entrust their data to some unknown and unmonitored external entity such as the 'cloud'.

Until that time, safe and productive cloud computing is just a fantasy. It's a solution in search of problem. Avoid it.

Comment: Re:ASIC is the real innovation (Score 1) 195

by fgodfrey (#47585405) Attached to: Inside BitFury's 20 Megawatt Bitcoin Mine

The ability to quickly design and produce an ASIC is hardly new or innovative here. ASICs are one of the few pieces of computing that you can get done faster if you just throw more people at the problem. Plus, I have a strong suspicion that most Bitcoin mining ASICs are Gate Array ASICs ( which, if my understanding of them is correct, use a bunch of standard layers and interconnect them with a few custom layers. That reduces the number of masks needed as well as reducing NRE charges and minimum quantities. Essentially, it's an FPGA where the interconnection is hard wired.

Now as to your prediction that multipurpose CPUs may go away (or become a small piece of a computer), that may turn out to be true. Special purpose ASICs to solve specific problems in high performance computing have been proposed many times, though to my knowledge, not actually built. At some point, though, someone will build one. Especially as the feature sizes stop getting smaller, going to custom logic to solve problems will be the next logical way to speed things up. However, the current generation of Bitcoin mining isn't going to be contributing anything to it.

Comment: JJ meets his Waterloo attacking high tech (Score 0) 514

by Simonetta (#47570623) Attached to: Jesse Jackson: Tech Diversity Is Next Civil Rights Step

JJ meets his Waterloo when he barges into the electronics lab. Even the black people in the electronics/high tech biz are about as far away from being black as you can be. All fifty of them.

For 400 years, the Afro-american community has been desperately breeding a certain type of individual. A type of person who can survive slave work and still pass their inherent africaness into the next generation. After 20 solid generations, they created the 'African-American'.

The technology industry is almost as old (if you see the industrial revolution and beginning of science as part of the tech industry). It too has created a certain individual type: the nerd.

The A-As and the nerds are about as far apart as people can be. All the characteristics bred into one group were bred out of the other group. They can barely talk to each other, even when they speak the same language.

The tech industry hires two types of people: nerds and people who support the needs of nerds. And since the tech industry is one of the most important industries in the world today, (along with food production and high finance) , they get to choose who they will pay to work for them.

The only reason the nerds will hire black people is as office pets. And then only the ones who know the difference between flux and a capacitor. And the ones "just know" without being specifically taught that you can type "ST7735R" into Google when you want to get the 250 page manual of a thin-flat-transistor screen. And who would never bring up the subject of "mah dih'que" in the workplace. Not too many people like this around, and the ones that are, are already working in the high tech biz.

So let's just redirect our conversation to the vast legacy of great JJ jokes that have written over the past half century. Old standards like:

Q: What's this? fee foh fii - fii fee foh foh A: JJ's telephone number (from 1977)

-or, the more esoteric,

JJ visited the Middle East and met with Palestinian leader Yassir Arafat. After the meeting, JJ was overheard saying to himself: "...been a long time since I said 'Yah, sir' to anyone".

Comment: Re:And the recovery system? (Score 1) 112

by fgodfrey (#47451641) Attached to: SpaceX Falcon 9 Rocket Blasts Off From Florida

Apparently (and this is my understanding with no inside knowledge, so take it with a grain of salt), they don't have live video telemetry from the stage during decent. They have a variety of engineering data, but to get decent video, they need to get the stage back. Given that it blew up, I'm guessing that's unlikely. Last time, they had some spotty video relayed off a tracking aircraft, but they had to wait for the aircraft to land before anyone saw it. Maybe the same will happen here? Also, as a company, I have a suspicion that they aren't thrilled with releasing videos of their rockets exploding. While a lot of people here understand that that's likely inevitable, given how complex a task they're trying to achieve, the general public probably won't....

Comment: Not exactly needed (Score 1, Interesting) 62

by Simonetta (#47258669) Attached to: A Seriously High Speed Video Camera (Video)

A 700 frame per second camera really isn't needed by very many people. It doesn't matter if a new design reduces its price by an order of magnitude.

What we need is the opposite: a very cheap camera with very high resolution and a very low price. Then we can put them on light poles and get good high-resolution courts-evidence-quality images of the people who are running out of nowhere to attack you, beat you senseless, and stealing your $500 bicycle when neighborhood is quite 100% gentrified yet.

At the present we have low-res video of "people" doing this, but they are rarely have enough resolution to positively identify the attackers.

Same with 'Flash mobs' that come into a store in groups of dozens, grab handfuls of stuff off the shelves, and just walk out in a large group.

Comment: Re:Progenitors? (Score 1) 686

by Simonetta (#47218297) Attached to: Aliens and the Fermi Paradox

The chances of advanced technological lifeforms developing is nearly infinitely small, and the distances between the ones that actually do develop are so great, that they never contact or even become aware of each other. Life forms on earth that are far in advance of humans are based on intelligence that evolved into post-biological form before one of the 100 million year cycles that periodically destroys all life on earth.

Comment: Re:parent delays (Score 3, Informative) 121

So tux2 was ready in 2000, and it took 14 years to rewrite it to avoid parents? Oh how much patents help innovation!

Few more years and those patents will expire and we can use both!

Tux3 is a better design. Tux2 was more along the lines of ZFS and Btrfs, that is, multiply-rooted trees sharing subtrees. Tux3 is a single tree with exactly one pointer to each extent. Considerably easier to check and repair. Of course we need to see if it turns out that way so please stay tuned.

Comment: Re:"With SysV init, unless I turned on some weird (Score 2) 533

by fgodfrey (#46956427) Attached to: Ask Slashdot: Practical Alternatives To Systemd?

What server do you have that makes it through the BIOS so fast that the difference between systemd and SysV is meaningful?

And if your server is so critical that the ~2 minute difference (on a good day) in boot times is a serious business issue, you should really consider running redundant servers anyway since there are a variety of other failures that a fast boot time isn't going to help....

Comment: Re:"With SysV init, unless I turned on some weird (Score 1) 533

by fgodfrey (#46956409) Attached to: Ask Slashdot: Practical Alternatives To Systemd?

Partially guilty. I certainly believe that a 2 minute boot time is acceptable *to me*, but I'm not irritated by people who want fast boot. I'm irritated that their zeal for fast boot resulted in an extremely poorly engineered piece of software that breaks the ability of some of my machines to boot *at all*.

Comment: Re:what's wrong with systemd (Score 1) 533

by fgodfrey (#46956393) Attached to: Ask Slashdot: Practical Alternatives To Systemd?

- Binary Logs: Sorry, but there is no advantage to not being able to easily look at a log file.

Technically, there is an easy way to look at the logs, it just requires a utility that is not cat or grep. But I get your meaning. Binary logs are certainly not my preference, but for tools that need to interact with and parse the logs, it is a necessity. There are ways to get your text logs back, though, and some distributions configure it this way by default.

...which will almost certainly break if the logs get corrupted at all. The great thing about text logs is that my brain can figure out what values are probably garbage and which ones are the remnants of the (now corrupt) log a lot better than a computer can. There are certainly ways of hardening binary logs, but why? syslog is a PITA to parse by machine not because it's text-only, but because the formatting is from the 1960's. I'm not arguing it has to be syslog format, just text.

- Failure to Log to the Console:

It is in the log.

...until you don't GET the log because it wasn't *WRITTEN*, which probably hasn't happened to you because you're probably booting a fairly standard configuration. But it took me 3 f'ing hours to debug the fact that my permissions were wrong on my NFS server when I was net-booting because I got no shell and no log (because the permissions were wrong). That would've take 20 seconds with logging to the console and knowing more about systemd wouldn't have fixed that.

- Failure to Drop to a Shell When It Breaks:

Once again, it is in the log. I'm not sure why being dropped to a busybox shell gives you a much better way to debug than just reading the log messages. If you want to test individual systemd services, you can do that with systemctl start/stop/etc.

Because sometimes it's a lot nicer to try to reproduce the failure right then and not have to reboot the system in order to get to the log. Remember, no shell means you can't read the log *at all* without rebooting.

However, if you use that command as root, it tells you not to run it as root. If you do it as a normal user, it doesn't have permission to read all the files to tell you what it's doing.

If that is true, it is a bug.

Maybe, but systemd --test --system prints "Don't run test mode as root" on OpenSuSE 12.3 and Fedora 20.... While trying a few other distro's to post this comment, I ran across "systemd-analyze --order --system plot" (which wasn't in the original distro that I was debugging, but it was ARM so maybe it was weird) which appears to be able to generate a graph in SVG, which, while huge, appears to help me a lot.

- Races: I no longer have any idea what order things are starting in.

If a dependency issue is causing your boot to randomly fail, then your systemd configuration is horribly broken. ... You don't know what order services are starting in because you shouldn't need to. The only thing your unit should do is specify a preferred ordering. ..

...until something doesn't work. Yeah, the config I've got *IS* horribly broken. I'd like there to be some reasonable way for me to figure out how to fix it. And sometimes I don't *PREFER* an order, sometimes I *REQUIRE* an order. On my desktop? Couldn't care less because it "Just Works(tm)' and I rarely change the distribution's defaults. On my servers, it's more complex. Maybe "prefer" in this case means it will always honor that?

Have you every really had to deal with the complexities of the sysV init system? It is not pretty. "Jiggling the cord" until it works is about all you can reasonably do with sysV when you have a complex init.

Yes. I obviously have no idea what your experience is, and maybe you had a horrible one with SysV. I've had my share of battles with it and I'd never argue it's perfect, but it's a lot easier to debug than systemd. When everything starts in serial order....

It doesn't "mount filesystems" at a single time during boot the way sysV does. You can move service files to other filesystems, but then you need to tell the service config that you did this so that it can bring up that filesystem before starting the service. This is actually a lot easier to do with systemd than with sysV.

In SysV, almost *nothing* happened before filesystems, so I rarely had to touch *anything* in /etc other than /etc/fstab when things moved. Now, I've gotta touch the config files for every service I move, which is easy if I wrote the service, but not so easy if I didn't and maybe don't even know what it's called. Why is this easier? I'm terrified of what's going to happen when I move a few subdirectories of /var to a different filesystem on a cluster, but I'm going to find out next week. I'm hoping to be pleasantly surprised....

Well, this is more of a rant than a series of legitimate complaints. You can't expect the systemd people to understand your issues if you haven't even taken the time to learn how systemd works first.

Yeah, it *IS* a rant. But that doesn't mean that the stuff I'm complaining about isn't a real problem. I've always hated the "let's make it complicated and blame the user if they can't figure it out" philosophy. I will waste hours figuring it out. Why is this a waste? Because in the end, I've gained *no* capability that I didn't already have except faster boots and since I boot my servers less than once a month, that gains me nothing. It's awesome that Linux is gaining share on the desktop. udev, for all its warts, was *sorely* needed since I don't wanna run "mkdev" every time I plug a USB device (etc). However, until systemd, the changes for the desktop played nicely (and in most cases added capability) to the server use cases. systemd just doesn't.

Oh, I knew I'd think of something else. systemd even managed to break shutdown on a netboot'd system since, apparently, it's weird set of dependencies don't check to see if the root filesystem is mounted over the network before shutting down the network.... Again, obviously distribution dependent, so if you know of one that can actually deal correctly with an NFS root, let me know...

Comment: Re:what's wrong with systemd (Score 5, Informative) 533

by fgodfrey (#46954207) Attached to: Ask Slashdot: Practical Alternatives To Systemd?

What's wrong with it? Here's my starting list and I'm sure I'll think of more....

- Binary Logs: Sorry, but there is no advantage to not being able to easily look at a log file.
- Failure to Log to the Console: There is nothing more frustrating than watching 5 screens of "Failed, use journalctl to blah, blah, blah..." come by when you know that your root filesystem isn't mounted read/write. There went *ALL* your debug information.
- Failure to Drop to a Shell When It Breaks: If my boot is broken,I want a shell. Not a hang. There's a way to force it to go to a shell, but that's before it does *anything* so you don't get to debug the failure, you get to guess what the failure might be and see if you can debug *that*.
- No way to see WTF it's doing: There's supposedly a command to make it tell you what order (and presumably what'll happen in parallel) things are going to start in. However, if you use that command as root, it tells you not to run it as root. If you do it as a normal user, it doesn't have permission to read all the files to tell you what it's doing.
- Races: I no longer have any idea what order things are starting in. I've had a cluster where everything worked fine. Until the a week and a few reboots later and then it occasionally failed. Don't even start to tell me that "I must have my dependencies wrong". I *KNOW* they're wrong. But I have no tools to help me figure out what "right" is. Plus, have you looked at how many unit files systemd starts on a normal system? I can't hold that much of a graph in my head. With SysV init, unless I turned on some weird parallel mode, everything starts in the same order every time.
- Complexity: I'm not a professional sysadmin. I'm a developer who has to maintain development systems (as well as personal systems) part time. If I worked with systemd every day, I'd probably be able to figure out ways to make it work for me. But I don't. SysV is just shell scripts. I *DO* deal with *those* every day so it's pretty easy to debug.
- Complexity, Part 2: The previous version of init essentially had no bugs. Ok, I'm sure that's not really true but they sure didn't surface very often. Since the results of your Process #1 dumping core are catastrophic (ie, a kernel panic), ideally that process should do as little as possible. That is *CLEARLY* not the design philosophy of systemd. Further, it consumes a decent amount of RAM and the more RAM you consume, the more likely (statistically) you are of hitting a memory error.
- YACL (Yet Another Config Language): Ok, so this is really a minor complaint but I get to learn yet another way of writing config files.
- Filesystems: SysV init tended to mount local filesystems *very* early in boot (some of that broke when udev got involved, but you could usually hack around that) and network filesystems not long after. I'm not entirely sure where systemd mounts filesystems, but it breaks *HORRIBLY* if you move some of the files needed by a service onto a filesystem that's not a "normal" filesystem. I'm sure there's some way to set all the dependencies to make that work, too, but see above, I have no f'ing way of figuring out what should depend on what.

From all outward appearances, the developers have *no* interest in fixing much of any of those complaints. The whole "debug on the kernel command line" fiasco is a pretty clear indication that they "don't play well with others". In the end, I'll see what Slackware has or maybe move (back) to the BSDs.

"A great many people think they are thinking when they are merely rearranging their prejudices." -- William James