Forgot your password?
typodupeerror

Comment: Practical alternatives (Score 2) 533

by rl117 (#46953871) Attached to: Ask Slashdot: Practical Alternatives To Systemd?

I've moved most of my systems to FreeBSD. And no-so-coincidental to this post, today I set up my first Debian GNU/kFreeBSD jail system. Works perfectly. Install debootstrap from ports, create ZFS volume, debootstrap onto the volume, configure and start jail. Done. (Works fine on the bare metal, too.)

(Sad to say this since I've been a Debian developer for over a decade, but I doubt I'll be using jessie in any serious capacity except perhaps for kFreeBSD if they don't manage to screw it over as well. I despair at what's happened to the major Linux distributions over the last few years. No longer feels like home, and the years of pushy passive-aggressive behaviour and acrimony which led to it being adopted completely killed my last bit of enthusiasm. I spend all my free time working on Debian.... for this? Giving the BSDs a try for the first time in a long long time, was like a breath of fresh air.)

Comment: Re:This would go over so well on IT (Score 1) 312

by rl117 (#46779687) Attached to: Switching From Sitting To Standing At Your Desk

I've done 12 hour shifts in working an industrial production lab, going around a huge site to collect samples and then working standing in a lab testing them, worked sitting and standing at a lab bench and at various bits of expensive lab equipment all day while doing my MSc and PhD, and now I'm working full-time at a desk as a software developer, developing multi-platform open source imaging software in C++ and Java (openmicroscopy.org).

I've found working at a desk all day to be the most singularly unhealthy activity I have ever engaged in. Doing a job which requires varying degrees of physical activity is much better. You aren't stuck at a desk for the entire day in a single position. After doing this for the last two years, I've ended up with RSI, muscular problems and suffer from chronic pain in various places. "Comfort" and sitting at a desk are about as far apart as I can imagine. Physical work doesn't automatically imply physical discomfort.

Comment: Re:Apple committing slow suicide, Tim Cook assisti (Score 4, Insightful) 217

by rl117 (#41943997) Attached to: UK Court Sanctions Apple For Non-Compliance

You seem to be suggesting that mere consumer popularity should permit that corporations can act effectively above the law, and that they can behave as illegally as they please. There are very obvious reasons why this can not be permitted! The law is the law, and Apple were found to be a pack of liars who are continuing to bring baseless legal action against their competitors. They have been hoisted on their own petard by their legal actions here, given that all of this is self-inflicted, and they are acting like a spoiled, petulant child.

While kind of offtopic, if Apple were to be banned from trading in the UK, I think you'd find that it would hurt Apple Inc much more than it would British citizens. There are plenty of other computer and gadget manufacturers out there who would pick up the slack. Apple just manufacture shiny, but limited, gadgets. The world does not revolve around them.

Comment: Steam on Linux (Score 1) 635

I for one will happily ditch windows gaming in favour of Linux as soon as Steam has decent coverage for the games I play. I've been wanting this for years, and it really is the primary reason I even have a windows partition--everything else is done on Linux. If Steam can set up wine nicely to play the non-native ports of games I own, I really won't have any reason for keeping it around.

Comment: No local user account by default (Score 2, Informative) 558

by rl117 (#40845641) Attached to: Windows 8 Is Ready

You can actually just use a local account--but it's not the default, and is quite unobvious. It took me several minutes to find, after being very reluctant to send all that personal information to Microsoft. I think that this subterfuge to prevent you having a local account by default is quite naughty, and I wouldn't be surprised if they get into trouble for it.

Comment: Re:minor typo - "makes impossibles" (Score 1) 277

by rl117 (#40728731) Attached to: Linux 3.5 Released

I lost a Btrfs RAID1 setup due to a SATA drive cable becoming unseated. Both drives were unrecoverable, and even oopsed the kernel when trying to mount them. Good job it wasn't important! Compared with the md RAID1 on the other half of the same drives (which automatically resynched without error), it was not particularly encouraging.

This wasn't the latest kernel I admit, and things have definitely improved, but I would personally still be reluctant to rely on it for important data until it's more proven.

Comment: Re:GNOME is a study in how to not architect softwa (Score 2) 237

by rl117 (#37975798) Attached to: GNOME Shell No Longer Requires GPU Acceleration

GNOME is a perfect study in how not to architect a software system. Everything about it is wrong.

The first mistake they made was trying to cobble half-assed object-oriented support onto C, rather than just using C++ or Objective-C. Everything about GObject is stupid and counterproductive. It makes writing code a real pain in the ass, since you need to use typecasting macros all over the place. Worse, this sort of code promotes library design that's slow and inefficient. To make it even worse, this style of C code is so convoluted that it is not optimized well by compilers, resulting in binaries that are far slower than they should be.

I don't think the overhead resulting from using C is substantial at all. Maybe you get more overhead than C++ by always using virtual calls but that is offset by not doing C++ magic like unnecessary constructor/destructor calls. You'll have to back this up if you want me to believe you.

You are incorrect here. In C++, if you choose to make virtual calls, you pay the price of indirection via a vtable (this pointer). That's it. You only pay the price in classes which have virtual methods. With GObject, all classes contain a vtable, i.e. all class methods take a pointer to the type instance, which contains within it a pointer to the vtable. Every GObject instance contains this overhead, which makes instantiation of GObject expensive, and additionally increases the memory required for every object. In comparison, you don't pay this overhead for C++ classes unless you actually require it. This isn't including the overhead of additional GObject features such as properties, which are both inefficient to process and are type-unsafe, and the use of "construction properties" in object instantiation. What makes it truly awful is that all this work to implement OO in C is mostly done by hand! You have to manually create your own vtables; you have to manually cast all types to the correct type, and if you get it wrong the compiler won't typically tell you. You have to understand the intricacies of how a C++ compiler works to implement an inferior version in C! Why would anyone willingly inflict this upon themselves?

But this is only the beginning of the GObject problems. When using GObject, the type resolution is done at run-time. Not only does this make programming unsafe--the many typecasts can hide typing issues, leading to failure at run-time rather than at compile-time, it has additional run-time overheads. Here are a few reasons: G_TYPE_CHECK_INSTANCE_CAST, G_TYPE_CHECK_CLASS_CAST, G_TYPE_CHECK_INSTANCE_TYPE, G_TYPE_CHECK_CLASS_TYPE, G_TYPE_INSTANCE_GET_CLASS. And you'll also need to check every function argument taking a GObject to make sure it's of the correct type with G_TYPE_CHECK_INSTANCE_TYPE (or commonly using a wrapper around it). This is not a cheap operation, it has to check the GType type register, which involves a string lookup in a hash table (GQuark, at least last time I looked). So you have several of those for every function call if you actually investigate the use of all the uppercase casting macros, and again inside the function. This is mostly absent for C++ code (the type checks and casts are done at compile-time), and C++ RTTI involves simple pointer comparisons of typeinfo objects; much faster, and again type-safe.

Here's an example of class using GObject: header source

This is the same class using C++ header source

The C++ version is type-safe. Several type bugs were found during the C++ conversion, not picked up by the C compiler using GObject. It's more efficient, easier to maintain, and more secure. The objects take up less space in addition. Overall, the C++ conversion had only positive effects. The current implementation is also available in git.

Back in the mid-to-late 90s, when GTK+ was being created, C++ on Linux was poor, and was not yet standardised. This is now no longer the case, it's very well supported and works very well. IMO it would make a lot of sense to make the excellent GTKmm and related mm bindings the real implementation (i.e. not wrapping the C version), which would really improve the quality of the system. Right now, even the GNOME developers do not encourage development using the C interface due to its many problems. Tools like Vala only paper over the problems--you still need to use the C interface to write a "native" GNOME application with access to all the interfaces, because GNOME is still fundamentally tied to the canonical C implementation, with all the problems that entails.

Regards, Roger

Comment: Re:Sadly OSX is not an option (Score 1) 294

by rl117 (#37127450) Attached to: Interview With GNOME 3 Designer Jon McCann

Err, yes, it most certainly does. Take a look at the underlying SSHFXP protocol; it's essentially a serial protocol that provides the UNIX filesystem API, i.e. open/close/read/write/lseek/chown/chmod etc., over the wire. This does allow it to be used directly as a filesystem, and is why we have the sshfs FUSE filesystem which utilises it.

Comment: Re:Still not looking good (Score 1) 442

by rl117 (#35645304) Attached to: Radioactive Water Found In Two Reactor Buildings

> The No.5 and No.6 reactors represent about 2GW of generation capacity they desperately need.

Totally agree. If they are undamaged and remain safely operable, why would they be left to sit idle once the immediate mess has been cleaned up. The other reactors are obviously write-offs though.

> The power reactor at the Windscale site was operated for 46 years after the graphite fire in the weapons reactor.

Why wouldn't they be though? Sellafield is a big site, around 1000 separate facilities in six square km, and the four Calder Hall Magnox reactors were entirely separate from the Windscale Piles. Calder Hall operated from 1956 to 2003, so it was obviously well under construction, and at least partially, if not fully, complete before the Windscale fire. My understanding is that the affected reactor was sealed and mothballed; no need to abandon the entire site, and that's now part way through being cleaned up and fully dismantled. Unlike Chernobyl, it's not like the immediate area was heavily contaminated and evacuated. Heck, I've been on holiday and been swimming in the sea within spitting distance of the place--it's not like the Windscale incident caused any lasting harm.

Comment: They just killed their main market (Score 1) 234

by rl117 (#35637670) Attached to: Nokia - No More Symbian Phones After 2012

I just bought a Nokia 1800. Not a smartphone, but I don't need one; I have a computer for all that stuff. Battery life: currently around 2.5 weeks with moderate text/call usage. Very simple, does all the basic stuff excellently though. Cost me £16 with £10 credit, so basically £6 for the phone.

This has a very similar interface to older Nokia phones I've used. I'm basically a happy Nokia customer. Am I at all interested in Windows Phone 7? No, and never will be. I was interested in the potential of the N900, but was far too expensive to justify actually buying. Shame we probably won't see what it's successors could offer.

I'm kind of sad the 1800 is likely the last Nokia product I'll buy, since prior to Elop it looked like they had a superb long-term strategy--they just needed a little longer to get it all together in the short-medium term, and they would have continued to be the best.

(Sheesh, Slashdot can't even handle a simple UTF-8 £ sign without mangling it.)

Comment: Re:Firefox Updates (Score 2) 250

by rl117 (#35119320) Attached to: Debian 6.0 Released In GNU/Linux, FreeBSD Flavors

This is one probable reason. If there's a security problem, then the distributor has the following options:

- wait until Mozilla releases a new version containing the security fix [but this may contain other, unwanted, changes]
- backport the security fix, but then get explicit approval from Mozilla before being allowed to make the release [may take too long]
- backport the security fix immediately, but don't wait for approval from Mozilla [but requires renaming to something other than "Firefox" to be compliant with the trademarks].

Additionally, Firefox and its related components are so complex and intertwined than it's often simply not possible to backport a security fix. In this situation the only choice is to upgrade everything to the latest version.

From Debian's point of view, you don't really want to push major new versions into a stable release, and especially for a security update. You want a minimal, targeted, testable fix which fixes a single issue only. That's one of the reasons why Debian chose to rename "Firefox" to "Iceweasel", because otherwise it is simply not permitted to release a security update.

It's also worth pointing out that distributors such as Debian also make changes to software to better integrate it into their system. "Firefox" would prohibit that as well, which is one reason why it's very much a standalone application that doesn't integrate properly into any desktop environment, and reimplements a whole bunch of the common functionality they provide.

Regards,
Roger

Comment: Re:yay. two more variants that nobody will want. (Score 5, Informative) 250

by rl117 (#35118448) Attached to: Debian 6.0 Released In GNU/Linux, FreeBSD Flavors

You should be aware that Debian is not allowed to use the trademark "Firefox" and also have the ability to apply patches such as security fixes(1). It's not called "Iceweasel" out of anything but necessity. You think this is a Debian-specific issue? Well, no, it's actually a major problem for all other distributors as well(2).

1
2

So the links are 5 years old, but the issues surrounding the trademarks haven't changed or gone away. Distributions shipping "Firefox" have abrogated their ability (and responsibility) to be able to apply changes and security updates to the software without the explicit concent of Mozilla Corporation.

Not exactly free software when it comes on those terms, is it?

Regarding the kernel, I assume you're referring to the non-free firmware removal. Maybe you haven't been fully informed that the non-free firmware was actually removed from the upstream kernel sources as well. As a result, the Debian kernels are far from "non-standard", they are standard!

Regards,
Roger

[FFS Slashdot, it's 2011 and you still can't handle UTF-8!]

Comment: Unicode in C, C++ and Perl (Score 2, Informative) 728

by rl117 (#34087146) Attached to: Mr. Pike, Tear Down This ASCII Wall!

One thing many people aren't aware of is that for several years now (since GCC3), GCC and G++ accept UTF-8 as their default input encoding, and internally store narrow and wide strings as UTF-8 and UTF-32, respectively. It's recoded to the output stream locale when you do any output. This means you can write your source code in Unicode (in strings and comments at least) and it all works perfectly. It has full support in the C and C++ standard libraries. I've been using it for years; it works perfectly. It would be nice to get support for UTF-8 symbols in the linker, so we can have UTF-8 variable names as well. The same applies to Perl, though perl6 even gives you the ability to have Unicode operators, and possibly variable names.

I do routinely use UTF-8 symbols in R (example: "deltaCt" can be replace with the actual Delta symbol [Slashdot ate the Unicode--seriously poor!]). It makes the code more readable, and entry isn't the massive issue people make it out to be. AltGr/compose keys handle the common symbols, and you can look up the few odd ones that aren't in the compose tables.

Having the ability to use Unicode does not in any way detract from the ability to use ASCII. Since ASCII is a strict Unicode subset, the ability to use Unicode imposes zero overhead on those who wish to stick with ASCII, so the extent of the hate seen for wanting a bit of progress is a bit shocking. People pointed out how unreadable code could be made, but the reality is that when used sensibly and judiciously, it can make code more concise and readable.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522776 for information about some of the issues.
Having native Unicode support end-to-end by default is still a goal we want to achieve; the ASCII C locale is the last holdout. Getting a UTF-8 C locale is the last remaining step, though it'll take a few years to get there.

Regarding editing Unicode sources, both Emacs and vim have pretty decent Unicode support, and Linux distributions have had unicode support for a decade now, and really good support for at least six years. Broken tools are no longer an excuse for not using Unicode.

Regards,
Roger

Cellphones

Porting Lemmings In 36 Hours 154

Posted by Soulskill
from the first-in-line dept.
An anonymous reader writes "Aaron Ardiri challenged himself to port his classic PalmOS version of Lemmings to the iPhone, Palm Pre, Mac, and Windows. The porting was done using his own dev environment, which creates native C versions of the game. He liveblogged the whole thing, and finished after only 36 hours with an iPhone version and a Palm Pre version awaiting submission, and free versions for Windows and Mac available on his site."

The opposite of a correct statement is a false statement. But the opposite of a profound truth may well be another profound truth. -- Niels Bohr

Working...