Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment I'd consider this (Score 1) 114

I still have Mac Mini (Freescale PowerPC G4) which I used for Debian development for half a decade, and which is now idle with a FreeBSD 10.2 install at present, and while I went to Intel and AMD for my last two systems, I'd certainly welcome a return to an affordable POWER system. I've been pretty disappointed in the state of open hardware for a good while.

I was looking at the offer for an OpenPOWER system from Tyan (http://www.tyan.com/campaign/openpower/) but I'd prefer a workstation rather than a rackmount unit. If it can run FreeBSD, then even better. The only rub is the graphics support; if I can stick in an AMD board and have it work with OpenFirmware and the current open drivers, I'd be quite happy.

Comment Re:Why is Diablo showing this? (Score 1) 148

Because you might be streaming content into the texture after its creation e.g. with GLTexSubImage2D (or 3D). You might already be running the render loop a few times over before it's fully filled. Ideally the driver would only ever give you blanked memory so it would be transparent and imperceptible.

Comment Re:The brief puff of black soot... (Score 1) 496

Filtering out ultrafine particulates is hard. In a lab setting, most types of filters will clog immediately, and the backpressure is huge. You wouldn't be able to put one inline in an exhaust and not have it fail (rupture), clog or stop the engine in a matter of minutes. There are other ways of filtering, but doing so in a hot continuous exhaust stream is not a trivial problem to solve.

Comment Re:Dynamic prefixes make SOHO networking a nightma (Score 1) 294

Your prefix should be constant and should remain the same across reconnects. If you want the remainder to be constant, it should be constant with SLAAC, being based on the MAC address. If it's changing and you don't want it to, try disabling privacy extensions? Or you could use DHCPv6 or static allocation if that wasn't sufficient.

Comment Re:Practical question for consumers (Score 1) 294

My ISP gives me an IPv4 address and an IPv6 /64. So each machine internally gets a NATed IPv4 address (as is usual) and one or more global IPv6 addresses (some are configured statically e.g. server with DNS entry; clients use SLAAC and privacy extensions).

There's no charge for the 2^64 addresses. They aren't scarce and "valuable" like IPv4 addresses.

Comment Re:Many happy returns, IPv6 (Score 1) 294

You can make it a business case very easily. Call your ISP and ask them for some concrete timelines for IPv6 service. If they haven't got any, then cancel your subscription; when they ask why you're leaving, tell them that you want IPv6 and they aren't providing it. They'll get the message when they lose enough business.

I moved to another ISP with IPv6 service (aaisp) specifically because my existing ISP at the time had promised it was coming for two years without delivering, and put it on the back burner. I now pay a bit more, but have excellent service which includes IPv6 by default.

Comment Re:More than just attacked. (Score 1) 294

I have native IPv6 from my ISP. The ISP-supplied router handles v4 and v6 automatically. The router's firewall handles IPv6 exactly the same as it handles IPv4; if you want to open up ports, allow inbound/outbound connections, etc., it's all configured pretty much exactly as it was for v4. If people can handle configuring IPv4, then they can handle IPv6. Being "constantly pwned" is seriously overstating the risks.

Comment Re:make peace? (Score 1) 242

Seriously, have you even thought about this in any depth?

What's more safe and secure, many tens of thousands of lines of C running in PID0 with root privs, or interpreted scripts each running as root or with reduced privs in their own separate process?

It's obviously the latter. The only compiled code is the shell interpreter, which is well tested and used all over the place with root privs already. And the shell scripts being run are trusted. Now, you can argue all the other points about the downsides of shell vs unit files. But as for security, this one is plain and obvious. All that C is just dying for a trivial buffer overflow or some other standard exploit to allow a full compromise of the system from some valid or even user-supplied untrusted input. Yes, all that code is long overdue for a thorough audit; we're living on borrowed time as it is. How long to you think it will be until the first major exploit surfaces? Maybe then we'll have a rethink about the appalling design practices the systemd "geniuses" have foisted upon us. Having so much code running in the most critical and vulnerable part of the system is idiocy of the first order.

Comment Re:I've made my peace with systemd (Score 1) 242

Sounds good... right up to the point when there's a problem. Then what happens? systemd notices that the log is corrupt, and... deletes it. No log of the problem. See: the long and angry (and unfixed) bugzilla tickets.

As for log compression, you don't want the actively written log to be compressed. If there's a problem, even as small as a single bit error, then the log will be unrecoverable. That's the tradeoff you make with compression. logrotate compromises by only compressing older logfiles. If there are any minor errors in the active log then you can still read it just fine.

As for tampering. It's of minor importance only. While the systemd people and their fanbois might harp on about it, they are catering for a problem which is of far less importance than hardware failure or power loss. Right now, all that foward hashing is so useless. If a simple power failure causes the checks to fail and the whole log to be discarded, it's a net negative. You threw away all my bloody logs! Like many of the systemd features, there's a whole fanfare about how essential it is and how everything else is awful and insecure. And as usual, there's some small credence to the claims. But it's massively overblown, and it has significant downsides. The "scary" things you mention are all of low likelihood--they only apply if your system has been compromised; there are rather more likely and less nefarious things to care about before these. I'd rather have a guarantee that my logs won't be deleted on a whim. Never, ever delete my logs!

Comment Re:I've made my peace with systemd (Score 5, Insightful) 242

As an example for the problems with troubleshooting, I've recently installed a few Ubuntu 15.10 systems (bare metal and in VMware VMs). In both scenarios, NFS filesystems fail to be mounted at boot. Why? I have no bloody clue. There's nothing in the logs. If I umount them (they are showing as mounted but give immediate I/O error on use) and remount by hand it all works just fine. No idea how to troubleshoot it. With sysvinit I could boot to an interactive shell in the late initramfs and step through every script by hand, and pinpoint exactly where something was failing. With systemd, even with correctly configured systems, I still experience occasional unrecoverable hangs at boot as it screws up its nondeterministic boot ordering and waits forever on something or other (who knows what it might be). systemd has absolutely not improved boot reliability. If I boot a FreeBSD system with exactly the same NFS configuration, it mounts everything perfectly at boot every damned time.

Another thing, is the broken compatibility with what came before. Example: I edit /etc/nfsidmap.conf to configure NFSv4 id mapping. Previously I'd reload/restart the nfs-common service with 'service' or 'invoke-rc.d'. Job done. What's the systemd equivalent? I don't know, and I can't see any obvious candidate. Since both these commands now forward to systemd, a diligent engineer would have made the old service names forward to the new target(s) to retain compatibility, maybe with a helpful message indicating what the new names were. There's nothing. I don't see any obvious nfsidmap or generic rpc or nfs units. Yes, it's partly me lacking familiarity with the new way of doing things; but the lack of care in having a smooth transition for admins makes for a terrible time, and the mess of units makes the whole thing difficult to comprehend as a whole and baroquely overcomplicated.

Slashdot Top Deals

Nothing succeeds like the appearance of success. -- Christopher Lascl