Slashdot Mirror

Where are the great programmer's calculators?

Here: Qi Hardware's NanoNote makes a great programmer's calculator (including graphing/plotting with gnuplot), and it also does some other stuff well, too.

I got one early on, when they were only $100 (as did my wife, and a few friends), and it was worth every penny. These days they're selling for $150, and I'd say they're still worth every penny.

Where are the great programmer's calculators?

Here: Qi Hardware's NanoNote makes a great programmer's calculator (including graphing/plotting with gnuplot), and it also does some other stuff well, too.

I got one early on, when they were only $100 (as did my wife, and a few friends), and it was worth every penny. These days they're selling for $150, and I'd say they're still worth every penny.

Do you not find it a little hypocritical that you support free software, as it allows all the well known benefits like people collaborating, adding features, fixing bugs, using your code in unexpected ways, and producing generally awesome stuff; but, at the same time support deliberately breaking software designs (e.g. that of gcc), and making it hard to integrate them, edit them, and use them as a third party[1]?

Doesn't that make gcc just as bad as closed source software, as you're going out of your way to make it difficult to do all the great things that free and open software allows?

[1] http://comments.gmane.org/gmane.comp.gcc.devel/59296

Nick states here that their code doesn't link against any symbols marked GPL only, and according to the lkml itself, this defines what is permitted for non-GPL code. Of course, like you say, this interpretation hasn't been tested in court, but it does seem help RTS's case.

There's an alternative SCSI target implementation - SCST. I guess somebody was lying when they said the LIO/TCM target was "joining the Linux community". SCST is open and community supported. Looks like the wrong choice was made.

http://thread.gmane.org/gmane.linux.kernel/1078109/focus=1078310

Forums are some sort of locked garden from which it is hard to extract information in any other way than browsing the pages. What about other workflows? Also, I hate registering for one-time posts, and this is usually a huge turn-off from posting anything, even if it could have been useful to others.

When in need for this type of solutions, I tend to set up mailing lists, which is by far the most flexible. Then, to cater for other workflows I use GMane [0].

You just need to tell it to archive your mailing list, and on top of that, it can provide forum-like interfaces with various type of flows representation (threaded [e.g., 1] or flat [e.g., 2]) and a web-based reply [e.g., 3] form with no mandatory registration (depending on your mailing list configuration) but proper identity checks. And it also provides NNTP access for people who prefer newsgroups.

You can also host instances of Weaver [4] (archiver) and Loom [5] (web frontend) locally if you don't want to rely on external services.

GMane has a neat interface which makes it easily intregrable to web templates through a simple iframe, too [e.g., 6].

[0] http://www.gmane.org/
[1] http://news.gmane.org/gmane.os.openbsd.ports
[2] http://blog.gmane.org/gmane.os.openbsd.ports
[3] http://post.gmane.org/post.php?group=gmane.os.openbsd.ports&followup=58668
[4] http://weaver.gmane.org/
[5] http://loom.gmane.org/
[6] http://oml.mytestbed.net/tab/show/oml

Forums are some sort of locked garden from which it is hard to extract information in any other way than browsing the pages. What about other workflows? Also, I hate registering for one-time posts, and this is usually a huge turn-off from posting anything, even if it could have been useful to others.

When in need for this type of solutions, I tend to set up mailing lists, which is by far the most flexible. Then, to cater for other workflows I use GMane [0].

You just need to tell it to archive your mailing list, and on top of that, it can provide forum-like interfaces with various type of flows representation (threaded [e.g., 1] or flat [e.g., 2]) and a web-based reply [e.g., 3] form with no mandatory registration (depending on your mailing list configuration) but proper identity checks. And it also provides NNTP access for people who prefer newsgroups.

You can also host instances of Weaver [4] (archiver) and Loom [5] (web frontend) locally if you don't want to rely on external services.

GMane has a neat interface which makes it easily intregrable to web templates through a simple iframe, too [e.g., 6].

[0] http://www.gmane.org/
[1] http://news.gmane.org/gmane.os.openbsd.ports
[2] http://blog.gmane.org/gmane.os.openbsd.ports
[3] http://post.gmane.org/post.php?group=gmane.os.openbsd.ports&followup=58668
[4] http://weaver.gmane.org/
[5] http://loom.gmane.org/
[6] http://oml.mytestbed.net/tab/show/oml

Forums are some sort of locked garden from which it is hard to extract information in any other way than browsing the pages. What about other workflows? Also, I hate registering for one-time posts, and this is usually a huge turn-off from posting anything, even if it could have been useful to others.

When in need for this type of solutions, I tend to set up mailing lists, which is by far the most flexible. Then, to cater for other workflows I use GMane [0].

You just need to tell it to archive your mailing list, and on top of that, it can provide forum-like interfaces with various type of flows representation (threaded [e.g., 1] or flat [e.g., 2]) and a web-based reply [e.g., 3] form with no mandatory registration (depending on your mailing list configuration) but proper identity checks. And it also provides NNTP access for people who prefer newsgroups.

You can also host instances of Weaver [4] (archiver) and Loom [5] (web frontend) locally if you don't want to rely on external services.

GMane has a neat interface which makes it easily intregrable to web templates through a simple iframe, too [e.g., 6].

[0] http://www.gmane.org/
[1] http://news.gmane.org/gmane.os.openbsd.ports
[2] http://blog.gmane.org/gmane.os.openbsd.ports
[3] http://post.gmane.org/post.php?group=gmane.os.openbsd.ports&followup=58668
[4] http://weaver.gmane.org/
[5] http://loom.gmane.org/
[6] http://oml.mytestbed.net/tab/show/oml

Forums are some sort of locked garden from which it is hard to extract information in any other way than browsing the pages. What about other workflows? Also, I hate registering for one-time posts, and this is usually a huge turn-off from posting anything, even if it could have been useful to others.

When in need for this type of solutions, I tend to set up mailing lists, which is by far the most flexible. Then, to cater for other workflows I use GMane [0].

You just need to tell it to archive your mailing list, and on top of that, it can provide forum-like interfaces with various type of flows representation (threaded [e.g., 1] or flat [e.g., 2]) and a web-based reply [e.g., 3] form with no mandatory registration (depending on your mailing list configuration) but proper identity checks. And it also provides NNTP access for people who prefer newsgroups.

You can also host instances of Weaver [4] (archiver) and Loom [5] (web frontend) locally if you don't want to rely on external services.

GMane has a neat interface which makes it easily intregrable to web templates through a simple iframe, too [e.g., 6].

[0] http://www.gmane.org/
[1] http://news.gmane.org/gmane.os.openbsd.ports
[2] http://blog.gmane.org/gmane.os.openbsd.ports
[3] http://post.gmane.org/post.php?group=gmane.os.openbsd.ports&followup=58668
[4] http://weaver.gmane.org/
[5] http://loom.gmane.org/
[6] http://oml.mytestbed.net/tab/show/oml

Forums are some sort of locked garden from which it is hard to extract information in any other way than browsing the pages. What about other workflows? Also, I hate registering for one-time posts, and this is usually a huge turn-off from posting anything, even if it could have been useful to others.

When in need for this type of solutions, I tend to set up mailing lists, which is by far the most flexible. Then, to cater for other workflows I use GMane [0].

You just need to tell it to archive your mailing list, and on top of that, it can provide forum-like interfaces with various type of flows representation (threaded [e.g., 1] or flat [e.g., 2]) and a web-based reply [e.g., 3] form with no mandatory registration (depending on your mailing list configuration) but proper identity checks. And it also provides NNTP access for people who prefer newsgroups.

You can also host instances of Weaver [4] (archiver) and Loom [5] (web frontend) locally if you don't want to rely on external services.

GMane has a neat interface which makes it easily intregrable to web templates through a simple iframe, too [e.g., 6].

[0] http://www.gmane.org/
[1] http://news.gmane.org/gmane.os.openbsd.ports
[2] http://blog.gmane.org/gmane.os.openbsd.ports
[3] http://post.gmane.org/post.php?group=gmane.os.openbsd.ports&followup=58668
[4] http://weaver.gmane.org/
[5] http://loom.gmane.org/
[6] http://oml.mytestbed.net/tab/show/oml

Forums are some sort of locked garden from which it is hard to extract information in any other way than browsing the pages. What about other workflows? Also, I hate registering for one-time posts, and this is usually a huge turn-off from posting anything, even if it could have been useful to others.

When in need for this type of solutions, I tend to set up mailing lists, which is by far the most flexible. Then, to cater for other workflows I use GMane [0].

You just need to tell it to archive your mailing list, and on top of that, it can provide forum-like interfaces with various type of flows representation (threaded [e.g., 1] or flat [e.g., 2]) and a web-based reply [e.g., 3] form with no mandatory registration (depending on your mailing list configuration) but proper identity checks. And it also provides NNTP access for people who prefer newsgroups.

You can also host instances of Weaver [4] (archiver) and Loom [5] (web frontend) locally if you don't want to rely on external services.

GMane has a neat interface which makes it easily intregrable to web templates through a simple iframe, too [e.g., 6].

[0] http://www.gmane.org/
[1] http://news.gmane.org/gmane.os.openbsd.ports
[2] http://blog.gmane.org/gmane.os.openbsd.ports
[3] http://post.gmane.org/post.php?group=gmane.os.openbsd.ports&followup=58668
[4] http://weaver.gmane.org/
[5] http://loom.gmane.org/
[6] http://oml.mytestbed.net/tab/show/oml

In 2007 you made some rather polarizing remarks about C++. Coincidentally, Slashdot absolutely loves language wars and I seem to only find evidence that you use C based on the lack of malice and contempt I can find you publicizing on it. Do you find anything terrible about C? Conversely, do you have anything nice to say bout C++, Java, Ruby, Perl, JavaScript, Lisp, Prolog, Microsoft's languages or any other language you feel particularly vehement about at the moment?

It happened again, Linus flaming people gets stuff done.

It all started a year and a half ago with this innocent-sounding topic: [GIT PULL] omap changes for v2.6.39 merge window.

Of course it helped that most of the developers in the ARM community seemed to agree with the point Linus made. Other concerns had just taken priority.

Maybe I should also mention: the reason I originally got my NanoNote was that I was in a situation where, like OP mrhelio, Wi-Fi was more of a liability than a feature. Not having to worry about RF interference/EMI was a feature. I knew other people who had bought devices with Wi-Fi and then solved the problem by opening-up said devices and diking out the radio components, but I didn't want to have to bother with that.

That Zipit device also appears to have been out of production for a couple of years now.

And, speaking as someone who's used, loved, and even loved hacking on Rockbox, this is one of the big problems I see with it: since it's mostly working `against the grain', it basically doesn't run on anything that's still in production. On the occasion that the Rockbox hackers are able to accelerate the reverse-engineering project enough to port it to something that is still in production, that gets fixed pretty quickly. This was the case with the iPod that I bought specifically to run Rockbox, for example. When that iPod died, I accepted that Rockbox has an ever-enriching past, but no future. It's a pretty fantastic retro-system..., but it's still a retro system.

Apparently it's a security regression in the JDK, was analyzed and then patched in IcedTea yesterday

How did you conquer the catch-22 of needing experience to get the position that gives you the experience to get the position?

Wait, you're talking about needing to get the job before you can get Linux experience? The first thing you need to understand is how silly that statement is; we talked about this in my local LUG, a few months back, and one of the other guys summarised pretty aptly:

Even recent graduates have no excuse to not show some kind of
experience. Except for the hardware, all the pieces are freely
available, and with a bit of creativity/networking/paying attention
you can even come up free hardware. (I'd be willing to bet an old
computer (or sufficient parts to reconstitute same) that a request
sent to this list by a resource-starved student looking for free
hardware to use for learning would turn up more than one offer.)

So, when we hire, that's what we look for: experience that actually you can get in your spare time.

My own response to the question was longer and provides more specific suggestions.

> What people tend to forget about GNOME is that a large chunk of the developers are
> employed by Red Hat. GNOME isn't worried about losing users because regular users aren't
> supplying their pay cheques, Red Hat is and that's why they get to call the shots and you don't.

There must be some MS moles at Redhat, secretly working to destroy linux...

* GNOME 2 was usable; destroyed.

* Got your linux PC's hard drive nicely partitioned? Sorry, must repartition because they f'd up udev.

* Like your current init system (other than systemd)? Sorry, you'll soon have have to go with systemd as your init if you use udev. That's because udev code has been rolled up into the systemd tarball. http://article.gmane.org/gmane.linux.hotplug.devel/17392 At first they talked about long-term support for a separate udev. But they're rapidly changing their tune. See http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html
======
(Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't
noticed it yet. I am looking forward to the day when we can drop
that support entirely.)

Lennart

--
Lennart Poettering - Red Hat, Inc
=====

Some people are getting pissed off enough that they're seriously looking at running linux without udev. The common replacement is the mdev utility from the busybox build. See...
https://wiki.gentoo.org/wiki/Mdev
https://wiki.gentoo.org/wiki/Mdev/Automount_USB
https://github.com/slashbeast/mdev-like-a-boss
https://blog.stuart.shelton.me/archives/891

If you are looking for a free program to filter with... Snort does a good job. It is an IDS (Intrusion detection system), but it is flexible enough that it would work as a very good filter, allowing you to filter by keywords, domains, ports, have-at-you...

You can combine that with lists of questionable content and you'd have yourself a pretty effective and versatile system.

These kinds of rules are probably most relevant to your interests.
http://comments.gmane.org/gmane.comp.security.ids.snort.general/33780

It's possible to convert to the new unified filesystem without using anaconda, as described here and in the original reference here.

I can say from personal experience that the method described worked, without evidence of any problem, when I upgraded via yum from F16 to F17 on a hard drive dedicated to Fedora.

Set up a mailing list with a list manager such as GNU mailman, and then add it to Gmane to provide a web interface, and searching. (Gmane is also a mail-to-nntp gateway, but you don't have to use that part.)

We have every right irritated with Linus here. I've written software for Linux, Windows, and embedded RTOSes. Linux was by far the most painful. Boost was the only thing that made it tolerable. Berating a company that supports a user base which represents 1% or less of their market without any modern-day language tools at their disposal (STL, Boost, a decent IDE) is just counter-productive.

Seriously, if you write a device driver in Boost, you should be shot in front of your kids. And I know, I used to work for a company that wrote most of its software in Boost, luckily only in user space. They had all the usual problems with Boost, all the static and dynamic cast bullshit, 8 different kinds of smart pointers, all of them thread unsafe and of course, error messages the size of a small house. They had a bug for 2 years because they couldn't follow the code because of Boost and all Design Patterns they had used. There is a reason why Boost is not STL.

So no Boost or STL in the kernel is a good thing, only to keep coders like you out. Just read what Linus has to say about it:

http://article.gmane.org/gmane.comp.version-control.git/57918

(full dislosure: I now work for a company doing almost all coding in Erlang, and we rely on one peice of code written in Boost, and we hate it.
It is almost impossible to compile, lacks a good api, and if you change any configuration while it is running it drops all its connections. We really would like to replace it and probably will at some time.)

Why don't you ask RMS that? He designed gcc specifically to be less useful. Then he has the balls to go around claiming other peoples software is defective by design and start a big shitstorm.

This, perhaps:

http://comments.gmane.org/gmane.network.tor.devel/1099

One of the replies points to the non-technical problem with Tor on iOS, which is that Apple rejected it from the App Store as being a "proxy or circumvention tool." This is not terribly surprising, of course: Apple would not want to anger governments by shipping a platform that allows iOS users to evade national firewalls.

One mild irritation:

v = range(1, 5) print v

will output: [1, 2, 3, 4] instead of [1, 2, 3, 4, 5] (While this will make sense later, it's VERY confusing for beginners -- and it will bite them when the move on to other languages.)

No, it will prepare them. In most any language if you declare an array of size 5 you will index it from 0 to 4. Are you suggesting that range(5)[-1] act differently than range(1, 5)[-1]?

Since you admit it does make sense, what do you suggest? Have python ask you every time you run it how range should behave?

See also How Python handles data paying particular attention to the phrase "But this is not guaranteed behavior".

I read that I was astounded at the stupidity. That blogger completely fails to understand what "is" is for. You hardly need to use "is" and no beginner should even be told that it exists. Use "==" if you want to see if two things are the same.

And complaining that when you pass in what is effectively called an "array" in every other language and the subroutine modifies the array, that array actually gets modified?? What the hell? This behavior is no different than Java or C or Javascript or pretty well any language. If you want a new array, make a new array.

Don't even get me started on the hell whitespace rules cause for beginners.

Rules? You indent your code just like you would in Java or C, but you just don't bother also typing in the braces. What is difficult about this? I think it took me all of two minutes to get used to this when I first picked up python.

Actually Python's a nice choice - object orientation, some function programming features, the syntax is nice and clear and it's easy to learn.

OOP is a failure. The use of OOP cripples the mind; its teaching should, therefore, be regarded as a criminal offense.

Also, Python as a beginners language is the biggest joke I've ever seen. Having taught intro programming, I'd rather teach using Javascript (a terrible choice for beginners, btw) than Python.

One mild irritation:

v = range(1, 5)
print v

will output: [1, 2, 3, 4] instead of [1, 2, 3, 4, 5] (While this will make sense later, it's VERY confusing for beginners -- and it will bite them when the move on to other languages.)

See also How Python handles data paying particular attention to the phrase "But this is not guaranteed behavior".

Don't even get me started on the hell whitespace rules cause for beginners.

The only advantage Python offers is an interactive mode -- which is great for beginners -- but its many deficiencies far outweigh that one strength.

the lessons I learned from having to structure programs in PASCAL transferred well to 6502 assembler.

If by Pascal you mean BASIC, then yes. Old unstructured BASIC is where you learned how to structure programs in a way suitable for 6502 assembly.

And negotiating with people who try to relicense your code can be even worse. Look up the old OpenBSD/Linux/Broadcom driver issue. It's a fascinating thread, at http://thread.gmane.org/gmane.linux.kernel.wireless.general/1558/focus=1558. And there was clearly a great deal going on behind the scenes with both thoughtful and easily irritated people trying to resolve things.

er, no.

perhaps you could create a pair of complementary transforms that don't lose any *more* data when flipped back and forth between each other, but since you're going from (typically) 8-bit numbers to 8-bit numbers, there's loss in precision.

just look at the equations used to perform the transform, it's not too complicated.

see http://comments.gmane.org/gmane.comp.video.mplayer.devel/60699 and http://forums.virtualdub.org/index.php?act=ST&f=5&t=14892&hl=& for some starter material. and yes, i trust people who are actually av programmers more than joe random on slashdot who provides no evidence whatsoever.

and no, your software is most likely NOT storing all intermediate data in 32-bit-per-channel floats.

Tying NaCl to a specific architecture was a very bad move in the first place, and PNaCl doesn't help a lot.
LLVM bitcode isn't intended to be a platform-independent transport of code - it isn't frozen, so you'll have to tie yourself to a specific LLVM version, while LLVM is still improving a lot with each release.
Neither is it very portable - it isn't endian independent, and it reflects details of the ABI, which means you can't even portably call C functions. It's really just a compiler IR.

See also e.g. this post.

I can certainly see reasons that you'd want to tie a VM to the browser instead of being stuck with ECMAScript for every situation, but you need to bring a real, portable VM to the table. LLVM isn't it, and the idea of putting architecture dependent binaries on the web is patently ridiculous, as should be obvious just from the time NaCl spent as x86 only. Imagine if web site owners had to recompile their site for every new architecture that became supported. "This site is best viewed on a x86"

3.3 Identified Software. If you use the Redistributables, then in addition to your compliance with the applicable distribution requirements described for the Redistributables, the following also applies. Your license rights to Redistributables are conditioned on you (a) not incorporating Identified Software into or combining Identified Software with the Redistributables; (b) not distributing Identified Software in conjunction with the Redistributables; and (c) not using Identified Software in the development of a derivative work of Sample Code. ... Identified Software includes, without limitation, any software that requires as a condition of its use, modification and/or distribution that any other software incorporated into, derived from or distributed with such software must also be (f) disclosed or distributed in source code form, (g) licensed for the purpose of making derivative works, or (h) redistributable at no charge.

I have actually broken this contract myself, in implimenting an ASF header analyser: I edited the code in emacs, and didn't realise until a little while later that I was violating section c (The ASF version actually refers to using the specification, not to redistributables as the Windows EULA does, but the rest of the text is the same) which prohibits using identified software in development. Worse, I compiled it in GCC. I'm not the only programmer to run into this: http://permalink.gmane.org/gmane.comp.kde.devel.core/3570

Microsoft loaths open source with such intensity that to access the specification for ASF (The container used in the WMA and WMV formats) you have to agree not even to use an open-source editor to write the code. Oh, and just to add further insult, one of the other clauses forbids giving your software the ability to save in any format *other* than ASF... the idea being that once media is in ASF, it'd be impossible to convert it into any other format. The developer of Virtualdub had to pull ASF support after a Microsoft lawyer threatened to sue him for patent infringement.

*sighs* Yes, ICC can actually work on microcode level, and yes, CPU's can decode microcode.

How else do you think microcode patches are made for CPU's to work around bugs in the instruction set?

Hint: It's loaded at boot time, from flash RAM, and those patches are made, for example, in ICC. ICC has some optimization tools that can analyze the flow of the microcode in some intrinsics.

Hell, a lot of projects have microcode specifications, and both Intel and AMD regularly submit such references to Linux as can be seen here: http://comments.gmane.org/gmane.linux.kernel/1204282

As for your incorrect claim about the AMDvsIntel issue, everything hinged on the CPUID check. Anything Intel had a valid entry in the database, anything non-Intel might have been compatible, there just wasn't an entry for it, and was thus treated as generic x86.

Another incorrect point, they weren't convicted, they settled out of court, both with AMD and FTC.

I think you should put your geek card facsimile back into the cereal box you got it from.

PNaCl is portable because they'll use llvm.

LLVM is not portable, see for example http://thread.gmane.org/gmane.comp.compilers.llvm.devel/43769/focus=43770

It is very hard to try to make LLVM portable, which is what PNaCl is attempting. Maybe they will succeed, we will see in time.

Please stop spreading FUD. There have been 0 remote security holes discovered in djbdns.

Please lay off the crack, wake up, and smell the coffee. This kind of denial is flat-out dangerous.

I have a blog entry detailing the three security holes in djbdns and DJB paid the $500 security hole prize for djbdns years ago.

The most dangerous hole in an unpatched djbdns 1.05 install is the TCP "packet of death" that forces dnscache to restart (since SIGPIPE isn't caught by dnscache). I really should file a CVE for that security problem.

There is also CVE-2008-4392 as well as CVE-2009-0858; more information is in Debian's security page on djbdns.

Linux systems have an expectation that the root directory / and the /usr directory may be on different filesystems; thus /bin is expected to come with / and be available at boot time, where /usr may not be. This means that making /bin -> /usr/bin via a softlink would break that.

So what about doing the opposite? Would /usr/bin -> /bin work, or just create more & worse problems?

Separate question: Is it worth it? (No.)

I'm sure it's true that /sbin & /bin directories were split off from each other in the first place because of limited storage capacity, and obviously data storage is much less limited than in 1979, so that's not much of a concern for most Linux users.

Since 1979 (or thereabouts), Linux and UNIX-like operating systems have followed a particular, if arcane, way of organizing files. Now the Fedora Project is proposing a plan that will drastically change the way this filesystem hierarchy stores binary applications... if they can work out the potential kinks.

Specifically, the developers in the Fedora Project are proposing to move all executable files into the /usr/bin directory and their libraries into /usr/lib or /usr/lib64, as needed.

But does the fact that separate /bin & /sbin wouldn't be necessary any longer if we were engineering Unix from scratch (we're not!) mean that it's worth our trouble to change something that works, just to make backups prettier? Their argument fails to acknowledge that change requires effort, and that effort calls for justification.

Having all static, distro-specific, sharable OS in a single dir makes snapshots of the OS independently of its state and configuration truly atomic. In a btrfs world doing 5 snapshots of /lib, /lib64, /bin, /sbin and /usr instead of just one is not atomic, and hence racy, and ugly, and boooh!

Is there any other reason to fool with the Linux filesystem? Is there any good reason to fool with the Linux filesystem? I have yet to read one. Snapshots should be automated anyway, so whether it's five directories or one, they'll all be backed up via one script. So much for the "logic" that snapshots are "ugly" under the current filesystem hierarchy. Fedora's "solution" seems worse than the "problem" it's intended to address.

The other items from Poettering's essay at gmane are just arguments against specific reasons not to change the file system, but none offer any compelling reason why the effort is worthwhile. And it wouldn't just be the Fedora devs' efforts, it would entail forced effort of many other Linux users to adjust, and I don't see them taking that into consideration at all.

A nice theory, but completely wrong. See: http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1337

There's no such conclusion in the above thread. They're certainly discussing it, so I appreciate you pointing me to the thread anyway.

http://article.gmane.org/gmane.comp.sysutils.systemd.devel/1352
http://article.gmane.org/gmane.comp.sysutils.systemd.devel/1349

I still stand by my original statement.

A nice theory, but completely wrong. See: http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1337

There's no such conclusion in the above thread. They're certainly discussing it, so I appreciate you pointing me to the thread anyway.

http://article.gmane.org/gmane.comp.sysutils.systemd.devel/1352
http://article.gmane.org/gmane.comp.sysutils.systemd.devel/1349

I still stand by my original statement.

A nice theory, but completely wrong. See: http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1337

There's no such conclusion in the above thread. They're certainly discussing it, so I appreciate you pointing me to the thread anyway.

http://article.gmane.org/gmane.comp.sysutils.systemd.devel/1352
http://article.gmane.org/gmane.comp.sysutils.systemd.devel/1349

I still stand by my original statement.

Is it nonsense-week on /. or what?

Well, no. It appears to be bad summary week. And people replying without RTFA week. Actually skip the article even, read Lennart Poettering's post on fedora.devel.

Although this proposal sounds reasonable at first, actually implementing it is troublesome.

First, someone already has it working on their system so it's within the realm of possibility. The steps to do it. http://thread.gmane.org/gmane.linux.redhat.fedora.devel/155511/focus%3D155792

Linux systems have an expectation that the root directory / and the /usr directory may be on different filesystems; thus /bin is expected to come with / and be available at boot time, where /usr may not be.

They address that by saying "There is no way to reliably bring up a modern system with an empty /usr, there are two alternatives to fix it: copy /usr back to the rootfs or use an initramfs which can hide the split-off from the system." in https://fedoraproject.org/wiki/Features/UsrMove#Detailed_Description
They currently have to mount /usr early or bunches of things silently break. They mention in it in the mailing list thread.

For one thing, all of the filesystem recovery tools or anything else that would be required in an emergency at the command line would need to be built into the kernel initrd images, which could be done but which doesn't seem terribly reasonable.

Seems to me that's exactly what should be done. If / is corrupted then trusting your recovery tools on / seems like a bad idea.
http://fedoraproject.org/wiki/Dracut makes it easy enough to build custom initrd images.

It's not easy to implement it completely correctly, even in software. My approach is to create a large file which takes almost all free space, then TRIM its content and then just remove this file. Obviously, it's a bit racy if you have services which could suddenly need several more gigabytes of disk. On the other hand, TRIM-ing 160Gb SSD drives takes about 5 seconds, so I don't worry about it.

Here is a thread about it on linux-raid: http://thread.gmane.org/gmane.linux.raid/31941/focus=32022

As far as I know, there are no hardware RAIDs with TRIM support.

"The compromise of kernel.org and related machines has made it clear that some developers, at least, have had their systems penetrated. As we seek to secure our infrastructure, it is imperative that nobody falls victim to the belief that it cannot happen to them. We all need to check our systems for intrusions. Here are some helpful hints as proposed by a number of developers on how to check to see if your Linux machine might be infected with something"

Its not the only the browsers that need to support the newer versions of these protocols, but also the servers.

Maybe not. It appears that OpenSSL in 0.9.6d implemented a "fix" to TLS 1.0 that may not require a change to the server. The basic idea is that the browser injects message prefixes into the stream as a kind of "fake" IV, to keep the Javascript from having control of which messages get encrypted. This may stop the attack.

Furthermore, if the prefixes are formatted in a certain way --- total speculation --- it may be possible to get the server to filter them out even if it's not running the same software. Anyway, I can't imagine how OpenSSL would implement this fix if the servers don't support it. But I admit I'm just catching up on this aspect.

Here's a brief post describing the "fix":

http://article.gmane.org/gmane.network.openvpn.user/32566

And my speculation on how the attack works, in detail:

http://practicalcrypto.blogspot.com/2011/09/brief-diversion-beast-attack-on-tlsssl.html

If you use a VPN, you should be protected from "local" man-in-the-middle (MITM) attacks. By "local", I mean between your computer and the VPN server. A VPN doesn't protect you from a MITM attack between the VPN server and the webserver you are connecting to. But it does protect you to the VPN server if you are at an Internet cafe, hotel, or other untrusted network.

At least that's true for most VPNs that use software based on OpenVPN, which uses OpenSSL for encryption. A copy of an email from James Yonan was recently posted to the OpenVPN User's list. Bottom line of the email: OpenVPN uses OpenSSL for encryption, and OpenSSL has been patched since 2002 for the vulnerability which most people think is exploited by BEAST. As long as your VPN software uses a patched version of OpenSSL you should be covered, at least for the "local" MITM attack.

For example, VPNs based on Tunnelblick, a free and open source GUI for OpenVPN on Mac OS X is not vulnerable.

I had assumed you would have read at least a few of the replies etc.

c++ gives enough abstraction and odd feature combinations to allow people to make functional but a complete pain in the ass to maintain code.

While it can be more verbose, c is comparatively very straight forward, how easy code is to understand and maintain matters.

Um the "kernel" (by which I assume you mean Linux) is not written in C++. It should be, but it isn't.

There are reasons the kernel doesn't have any c++ in it (link is about git, but same deal for the kernel).

You see wrong. Linus has already said, when kernel.org is back up completely, github will be just a mirror.

Linus has said that when kernel.org is back up the github repo will be turned into a mirror.

Has Linus changed his mind in the last week?

http://article.gmane.org/gmane.comp.file-systems.ext4/27628

No. The github address and bad grammar made Linus suspicious about the sender's identity. It had nothing to do with github itself.
See the comments here.

Has Linus changed his mind in the last week? http://article.gmane.org/gmane.comp.file-systems.ext4/27628

Security is not the focus, this has been made clear.

Exactly.

The problem is not that adding support to a new board in Linux is too hard, in fact, it's almost the opposite. There are already tens of slightly incompatible boards to support, and every time a company makes a new one, they don't even try to stick to any standard (not that there even *exists* a real standard), since it's very easy to just add new code to Linux. See this LKML thread for Linus's description of the problem from some time ago.

Using a microkernel doesn't help at all; you still have to code for all of the slight incompatibilities, regardless of whatever differences in logical organization.