Please create an account to participate in the Slashdot moderation system


Forgot your password?

Comment Re:Looks good (Score 1) 94

That's great, if you're only using KDE apps. What about apps that are neither KDE/Qt or Gnome? VLC is the first that comes to mind. xmms2 is another. Or, what if I want to use WinAmp through Wine? All of this just works in MATE/Gnome/Cinnamon with gvfs.
The media playing apps should be file system agnostic -- they shouldn't have to know about URLs or network protocols.

I just tested this with FTP and Audacity, and the files are copied to temporary directories before being opened in non-KDE apps. (Actually, they're copied for both, but to different directories for some reason...)
I'm using Sabayon with KDE 4.13.0 - you're either using an older, buggy version, or there's something wrong with your setup.

Comment Re:All but another GNOME3, please (Score 1) 94

I'm not sure about Plasma-next, but I could comfortably run KDE 4.10 (or thereabouts) on a tiny little Tegra 2 clocked at 1 GHz with 1 GB of RAM and no hardware acceleration. Chrome ate more RAM than KDE ever did. I've also used KDE quite comfortable on a Pentium 4.

So if KDE doesn't run on your desktop, then I'll wager one of the following is the case:
-you have horribly broken graphics drivers. Try changing the compositing mode, graphic driver, etc.
-your PC is over a decade old
-you have stumbled across an extremely rare and specific bug in KDE

Comment Re:KDE 3 (Score 1) 94

And with baloo replacing nepomuk, email search finally works - far faster than kmail1 ever was, I have over a 100,000 msgs which it can full text search in seconds.

If you're using 4.13.0 (the first version with baloo), or about to upgrade, here are two things I learnt the hard way:

  • When KNotes asks if you want to migrate your notes, say no. The migration process wipes them, and recovering them is non-trivial.
  • If you have any virtual machines, make sure you've got limits.conf set to prevent baloo from eating all your RAM

Such is life on the bleeding edge...
But apart from that, Kmail/Kontact works great for me (especially with Kolab).

Comment Re:If not... (Score 1) 865

And yes, all machines - including cars - should have a kill switch that mechanically cuts off the power. Industrial machines are required to have those, so why should land missiles mostly operated by amateurs be exempt?

Most industrial machines are electrical; the kill switch is just a switch. Implementing something similar for an IC engine is probably considerably more complex.

Comment Re:Reason to use end-to-end encryption (Score 1) 88

If I know Tony Abbot and co, there are government law drafters who have been given the task of taking the UK RIP act (the one that lets them send you to jail for refusing to hand over encryption keys) and invent a similar law that fits the Australian system.

They'd be a bit late.

Comment Re:How the west wasn't won (Score 1) 216

It sounds more like an approximation. Given a failure rate of p and 2 (non-redundant) engines, the probability of system failure is 1 - (1 - p)^2 = 2*p - p^2. p > p^2, which means we can neglect the squared term, leaving just 2p.
It's not the sort of thing you'd do in a rigorous analysis without formally stating the justification, but it's exactly what I'd expect from a back of the envelope approximation or an informal explanation. Someone with a strong background in probability would probably do this sort of approximation almost subconciously.

Comment Re:memset() is bad? (Score 1) 171

But the program performs functionally the same.
That's the rule followed when doing compiler optimisations.

memset has nothing to do with Heartbleed by the way, nor does any compiler optimisation.

The program will generate the same output yes, but the security implications are not the same.
This is actually tangentially related to heartbleed - if the memory had been zeroed when freed, the scope of the exploit would have been greatly reduced, as only currently allocated blocks would have been vulnerable. Furthermore, the most common reason for using custom mallocs in security-critical applications is to do exactly that - to zero all memory immediately upon freeing.

Zeroing memory like this is a common practice in such cases.

You also don't guarantee the original data is overwritten. If your application is paged out of RAM before the call to memset, when it gets loaded back in to RAM it can be pointing to a different physical memory location. You're now overwriting.... something completely different.

This is completely incorrect. Until it is freed (or realloc'ed), the address returned by malloc will point to the same data, regardless of whether it is in the L1 cache, RAM, or paged to disk. Were this not the case, each program would need to implement its own MMU.

Now, what is true is that additional copies of the data could be made, but you'd need to have escalated to root to access anything in a pagefile (at which point your system is completely compromised anyway), and I'm not even sure if direct access to L1 cache is possible.

Comment Re:memset() is bad? (Score 1) 171

If you call memset on some allocated memory and then free that memory, what (apart from clearing sensitive data from physical RAM) functional difference does removing the call to memset make? None?

The longer the data remains in memory, the wider the window to read it via some other exploit. (Also, anything running as root could potentially access it.) This is precisely what happened with Heartbleed.

Comment Re:I'm disapointed in people (Score 2) 693

See, that's the thing. You got used to changing your fonts around because in the old days fonts sucked. We didn't really have a good font system. All the other non-free desktops had a great font rendering system. Now we have something decent, you shouldn't have to screw around with fonts. It should just work. That's why GNOME doesn't have that many options for fonts. Neither does OSX nor Windows. You can still do the same kind of font fiddling before, you just have to use gsettings or tweak tool to do it. But they exist, but we need to build something greater. What we're doing is much harder, making things work for the general case.

People change fonts when the defaults don't suit them, and there is no one choice that will suit everyone. The logical conclusion of this is that you need to have some method by which people can change the setting, or your software will not be suitable for a significant number of people.

Sane defaults do not remove the need for configuration. Look at KDE - their defaults are perfectly fine for most people, but Plasma is /way/ more configurable than Gnome 3. This one-size-fits-all attitude is the primary reason people have responded poorly to Gnome 3.

GNOME offends people who use computers as a creative extension of themselves. ... I used to be one of those people, but life is too short, I prefer to take what I am given and work on the things that really matter to me.

False dichotomy much? Changing the font size should be a trivial task doable in under 5 minutes (including the time taken to Google it).
Furthermore, has it not occurred to you that people who use computers as extensions of themselves are actually the majority of Linux users? Minor changes that make our tools easier or more efficient to use are the norm for us. If we weren't interested in changing our tools, we wouldn't have installed Linux in the first place.
It's all well and good to target other demographics, but if you alienate your userbase and focus on a minority, then it should hardly be surprising when your users (and their funding) disappear.

It definitely comes from an older era where you can spend hours tweaking conf files.

I disagree. Spending hours tweaking conf files was the norm back in the 90s out of necessity, but the idea of customizing your tools to suit yourself is not specific to that era. I'm young enough to not remember most of the 90s and have used Linux for less than a decade, but I often spend time customizing my setup to suit myself better.

Comment Re:Not malicious but not honest? (Score 1) 447

If they were using a custom malloc, then they should have been memset (or similar) to zero the blocks when debugging. That way, use-after-frees still manifest as crashes when testing (it could be disabled in release builds to improve performance).
I'm in no way an experienced C programmer, but if I were reimplementing something as core as malloc/free I would include a ton of sanity checks and safeguards to make sure that, at least on debug builds, this sort of bug was obvious.

Comment Re:It produces performance like C++ (Score 1) 217

But wanting a GC has nothing to do with "brain dead idiots". It has been established decades ago that manual memory management is simply prone to errors, as program size increases. That includes expert programmers. This is a settled empirical question. If the overhead is acceptable, there is little reason to not want a GC.

There is also a third option: manual memory management with compile-time guarantees of safety. You get the performance of manual memory management without the risks, and the code ends up being more concise because heap allocation is implemented as a syntax feature. Rust is the most well known example of this.

Comment Re:It produces performance like C++ (Score 1) 217

Then again, you could just pick full C++ 11, which has the advantages of both the higher level of abstractions like C#, and the low level capabilities of C.

Speaking as someone who has worked with both C++11 and C#, C# is a much nicer language. C++11 improves things somewhat, but it's an old language and the cruft shows. The obvious example is generics: C#'s generics are quite straightforward to use, support constraints (base classes of type parameters), and can even be annotated to handle inheritance correctly. C++'s templates are notorious for their poor usability, to the extent that even Stroustrup recognizes that they fall short. A future version of C++ is supposed to implement Concepts, which provide the ability to add arbitrary constraints to type parameters (but not by using inheritance*, for some reason.)

It's quite telling that even though I've been using Linux as my primary OS for a few years now, I still haven't found a language that's as pleasant to use on it as C# was under Windows. (Qt is much nicer than the .NET Framework though.)

*To be fair, inheritance has the problem that once a class is written, you can no longer add base classes to it. But this is not insurpassable; C# supports extension methods that could be used to fix this in a manner similar to Haskell's type classes.

Comment Re:I avoided bluetooth for years... (Score 1) 180

I avoided bluetooth for years becuase it was unreliable and awkward. The headsets were expensive and uncomfortable. Some didn't work in that they required pairing every time you turned it on. (Both the phone and the device completely forgot about each other.) Buying a corded headset was far cheaper, had far better quality, and was far more comfortable.

But times change, as do needs. Most bluetooth devices now have just enough non-volatile memory to remember what they were last paired with and most bluetooth hosts will quite happily keep a list of every device it's ever pair with. Other than the initial setup (which can still be awkward and annoying) it's quite simple to use now. Hold the button for a few seconds until the light blinks and/or the sound chimes. Now I have a whole host of bluetooth devices.

It's funny you mention this, given that just a few days ago I struggled and eventually gave up on getting my laptop to pair with a Bluetooth ODB adapter that had previously paired with a different laptop. (In the end I gave up, took it apart, and soldered some wires directly to the serial interface inside it, as I had a USB UART adapter on hand).

The problem was that the device kept disconnecting after I connected to it, and there was nothing I could do to convince it otherwise. The more complex a technology is, the harder it is to get the interface right. This goes doubly when you have an embedded system without a second, more powerful interface (compare this to how Linux supplements the GUI with a terminal). Wearable devices take this to an extreme; the interface is more limited than that of a phone, so it's even harder to get right.

Slashdot Top Deals

Premature optimization is the root of all evil. -- D.E. Knuth