Slashdot Mirror

I tried to find an X server for DOS some years ago and came back empty. A bit surprising for me.

There apparently used to be a commercial xfree for dos called xappeal but it seems to have pretty well vanished.

There were several commercial X servers for Windows 3.1, like Chameleon Xoftware. Chameleon also had a good TCP stack for Windows 3.1, but the one that Microsoft eventually released is also adequate for this purpose. Or if you can find the TGV stack, that was the fastest. It seems unfortunate to have to run Windows just to run an X server on your DOS machine, but it's an option.

SQLite is controlled by a corporation, and that corporation requires adherence to a religious code in order to contribute patches to what is (in theory) an open source project.

Open source, absolutely, open contribution, absolutely not:

But SQLite is not open-contribution. In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept patches from unknown persons. All of the code in SQLite is original, having been written specifically for use by SQLite. No code has been copied from unknown sources on the internet.

But even if they were open contribution, they make it very clear they only insist your stick to the spirit of the specifics of the code of conduct to be a part of the community. Maybe go to the effort of reading its overview? See also the background story on its adaptation.

Forking is a poor alternative because they've got extensive test suites that are not open.

So no, I don't care what the maintainers believe in their own little heads, but if they require contributors to hold those same beliefs, it's going to cause problems.

"In their own little heads" shows you don't have the slightest bit of grace required to conform to the spirit of this 1,500 years tested "Code of Conduct", and but it will only cause problems in your mind, they most certainly can do without your non-existent to date contributions to the community. In that, it's functioning as useful filter to keep griefers like yourself away from the project.

I'd also predict this will put a damper on their revenue.

As the KJV puts in in Mark 8:36:

For what shall it profit a man, if he shall gain the whole world, and lose his own soul?

There's no more widely used piece of FOSS in existence, I'm sure there quite willing to take the very small hit they're going to get from intolerant bigots who will stop paying them money because they're Christian. Which would have happened anyway sooner or later, whether or not they'd adopted this code.

It's all around a bad idea for a for-profit corporation to start proselytizing,

And why is this?

if I was their customer (or my company was) I'd certainly drop the contract at the next opportunity.

Empty words from someone who was never going to be one of their customers.

They are objecting to the use of a joke when having a CoC is regarded as a somewhat serious issue.

The top dog of the SQLite project is a devout Christian, and is 100% serious about this being a real CoC. Especially seeing as how it's stood the test of time, 1,500 years and counting. As he said:

So then, why not use a more modern CoC? I looked at that too, but found the so-called "modern" CoCs to be vapid. They are trendy feel-good statements that do not really get to the heart of the matter in the way the the ancient Rule does. By way of analogy, I view modern CoCs as being like pop music - selling millions of copies today and completely forgotten next year. I prefer something more enduring, like Mozart.

He also considered "Benjamin Franklin's 13 virtues (http://www.thirteenvirtues.com/) but ended up going with the Instruments of Good Works from St. Benedict's Rule as it provide more examples."

SQLite not only has a lot of developers

Lie, it has only a handful for the SQLite system and its extensive test suites, and everyone one of them agreed to this COC.

but also has conferences and other meet-ups, and sadly from experience people have had problems at those kinds of events in the past.

Cite the incidents or we'll assume you're lying as much about them as well. Also point out how they're not covered by this CoC.

So clearly, all who were actually contributing to SQLite did not have a problem with it, as they would undoubtedly caused a stink at the time if they did.

The project head added this CoC with unanimous approval from current contributors.

Secondly, I view a CoC not so much as a legal code as a statement of the values of the core developers. All current committers to SQLite approved the CoC before I published it. A single dissent would have been sufficient for me to change course. Taking down the current CoC would not change our values, it would merely obscure them. Isn't it better to be open and honest about who we are?

but being over 1000 years old it's amazing how well it still would work as a guideline for a modern CoC.

Rather, the fact that it's stood the test of time for our sorts of communities is exactly why it still works 1500 year later, and an explicit reason for choosing it.

According to the article:

Not every machine is susceptible to the attack. For it to work, AMT has to have been both enabled and provisioned... It can be provisioned by default if vendors used a feature called "Remote Configuration" with OEM Setup

So, which computers have "Remote Configuration" with OEM Setup? These are the computers that are vulernable the moment you take them out of the box and plug them in.

For example, are Lenovo ThinkCentres vulnerable out-of-the-box? I recently read a report of an indivual complaining that his ThinkCentre M58P is affected by this vulnerability:

http://openbsd-archive.7691.n7.nabble.com/How-are-people-dealing-with-the-Intel-AMT-BIOS-vulnerability-backdoor-td318400.html

That may be the reason for commercial applications, but even in the free software space shared libraries are completely dominant, so dominant that in some cases it's becoming impossible to statically link even if you control the build process.

I ran across this mailing list thread from Freebsd-Stable about static linking:

http://freebsd.1045724.n5.nabb...

I'm not enough of a developer to fully comprehend the reasons, but it sounds like dynamic linking is so baked in that it's just not possible to statically link in some libraries. Perhaps if you built the source code into yours and tweaked the limiting functions, maybe, but the level of effort it involved would be huge.

Granted, this release does break things a bit further than most, as mentioned by post about time_t incompatibility. For example, the password database may need to be updated (by running a new version of pwd_mkdb , as mentioned by a forum post: updating past 5.4 current flag day). So, that database is a binary update that is required.

It is also true that this is a case of the operating system requiring that binary executable files to be re-compiled. However, breaking compatibility with older executable files is actually something that is pretty much always happening between OpenBSD releases. So that's not at all unusual.

Let me explain a bit about OpenBSD compatibility between versions: The operating system and pre-built ports are generally filled with dependencies of libraries, and seemingly little to no tolerance for different versions. This means that most binary executables will be designed for a specific version of the OS. Using binary executables for any other version of the OS will break things terribly.

The end of OpenBSD FAQ 5: section on OpenBSD Flavors states, “It is important to understand that OpenBSD is an Operating System, intended to be taken as a whole, not a kernel with a bunch of utilities stuck on.” The kernel and other software is meant to match. http://www.openbsd.org/faq/faq15.html#NoFun (gotta just love the name of that hyperlink anchor) is about "using a system and ports tree which are not in sync." In other words, if the "system" (e.g., the kernel) and the "ports tree" (i.e., "other software") are different versions, then you're likely doomed. Upgrading software to the "-stable" branch is generally an exception, meaning that it is okay as long as you're still within the same version number. Upgrading to a new -release involves upgrading to a new version number, and that's when hopelessness starts to seep in. Upgrading to the "snapshots" release, involving "-current" source code, is also likely to cause some incompatibilities. (Possibly not. But the likelihood increases over time, especially as soon as something common like libc ends up getting an updated version number.) The only intended and recommended way to deal with these problems is to just avoid them altogether, by upgrading absolutely everything (operating system and all the software) at once, which keeps things in sync.

This does get discussed further at ][CyberPillar][: updating OpenBSD via binaries in the subsection titled "Code sync requirement (and ramifications of this requirement)", which describes this issue more and provides additional hyperlinks.

This is why every single "port"/"package" (third party software) needs to be updated (for the easiest experience) with every applied OpenBSD version upgrade (in order to have the easiest experience). There is no "let's upgrade one piece of software today, and then upgrade another piece of software next week". It's an all-or-nothin' deal.

Did you read about the latest feature added by some piece of software? Sure, you can download a pre-built binary executable file from the "snapshots" release to try out that new software. If the software runs, great. If there's a problem with needing another library, then there's another solution using pre-built binary executables. Simply make sure to upgrade your entire friggin' operating system to the "-current" (a.k.a. unstable/testing branch), and all other software, all at the same time. That should avoid version compatibility issues.

Sound too challenging? Then break out your compiler and compile from source, and handle any dependency/version confl

Mozilla allows that, too. There's a slimeball company that takes over abandoned Firefox add-ons, adds spyware, and puts them up on Mozilla's "store". They did this to BlockSite. Users were very angry.

Mozilla's reaction? Mozilla's add-on policies prohibit this: "Whenever an add-on includes any unexpected* feature that ... compromises user privacy or security (like sending data to third parties)" ... "These features cannot be introduced into an update of a fully-reviewed add-on; the opt-in change process must be part of the initial review." The spyware was just fine with Jorge Villalobos, Mozilla's add-on project manager, who wrote "That's outdated, since we don't enforce that policy."

You can't trust the Mozilla Foundation any more. That's sad.

The problem with "XFS" eating data wasn't with XFS - it was with the Linux devmapper ignoring filesystem barrier requests.

Gotta love this code:

Martin Steigerwald wrote:
> Hello!
>
> Are write barriers over device mapper supported or not?

Nope.

see dm_request(): /*
                  * There is no use in forwarding any barrier request since we can't
                  * guarantee it is (or can be) handled by the targets correctly.
                  */
                if (unlikely(bio_barrier(bio))) {
                                bio_endio(bio, -EOPNOTSUPP);
                                return 0;
                }

Who's the clown who thought THAT was acceptable? WHAT. THE. FUCK?!?!?!

And it wasn't just devmapper that had such a childish attitude towards file system barriers:

Andrew Morton's response tells a lot about why this default is set the way it is:

Last time this came up lots of workloads slowed down by 30% so I dropped the patches in horror. I just don't think we can quietly go and slow everyone's machines down by this much...

There are no happy solutions here, and I'm inclined to let this dog remain asleep and continue to leave it up to distributors to decide what their default should be.

So barriers are disabled by default because they have a serious impact on performance. And, beyond that, the fact is that people get away with running their filesystems without using barriers. Reports of ext3 filesystem corruption are few and far between.

It turns out that the "getting away with it" factor is not just luck. Ted Ts'o explains what's going on: the journal on ext3/ext4 filesystems is normally contiguous on the physical media. The filesystem code tries to create it that way, and, since the journal is normally created at the same time as the filesystem itself, contiguous space is easy to come by. Keeping the journal together will be good for performance, but it also helps to prevent reordering. In normal usage, the commit record will land on the block just after the rest of the journal data, so there is no reason for the drive to reorder things. The commit record will naturally be written just after all of the other journal log data has made it to the media.

I love that italicized part. "OMG! Data integrity causes a performance hit! Screw data integerity! We won't be able to brag that we're faster than Solaris!"

See also http://www.redhat.com/archives/rhl-devel-list/2008-June/msg00560.html

There's a lot more out there if you care to look.

Toss in other things like the way Linux handles NFSv2 group membership (More than 16? Let's just silently drop some!) and lots of fanbois wonder why I view Linux as little better than Windows. Hell, Microsoft may fuck things up six ways from Sunday, but they're not CHILDISH when it comes to things like data integrity.

Although Struts 2 is a complete rewrite, it's backward compatible with Struts 1.

Rubbish, it has entirely different concepts, architecture configurations and just about everything. There are migration tools, but these are far from automatic.

Developers have had years to start making the switch.

True, but many haven't because if you have a website in maintainance mode (a small number of upgrade and changes) it is hard to get approval for an upgrade if what you are using is still supported. I am actually pleased that it is now at end of life, we have been wanting to evaluate new frameworks and upgrade for ages but not given the budget.

I'd rather lose UPDATEable views and finally get materialized views

There is quite a bit work going on on an initial implementation of matviews targetted for 9.3; losing updatable views wouldn't be likely to help you get matviews any sooner.

Right, suggestions like the Zenoss commentor who says "f you dont want to frack around, just chmod those puppies 777" are the reason why this is a problem. It's sadly common advice in the "I want setup to be easy" land of MySQL priorities.

Note that if you change the directory a PostgreSQL server writes to so that other users are allowed to write there, too, the server will refuse to start until you fix the permissions so that isn't the case. New database installations made with initdb have the right permissions, but the code checks against people "fracking" themselves by making them less secure later. The only way around this is to modify the source code to disable the check!

after paging through the code a bit, i found it interesting that they use java in their implementation (not just corona, but hadoop as well). i was wondering why, and after some googling found this link which helped explain the situation a bit clearer.

pretty interesting stuff. but id be willing to bet googles map reduce is written in c/c++

He could just keep the system as it is, but slap a search interface onto it and have it index its files and their content -- to make them easier to find.
http://serverfault.com/questions/40356/open-source-alternative-to-google-appliance-for-intranet-search
http://university-web-developers.1112205.n2.nabble.com/Moving-away-from-a-Google-Search-Appliance-GSA-advice-td6509523.html
https://developers.google.com/search-appliance/documentation/68/secure_search/secure_search_crwlsrv
http://docfetcher.sourceforge.net/en/index.html

I assume that Google Drive will get that capability soon, but right now, it doesn't have it.

There is a serious problem with this patch on BSD kernels. All of the BSD sysv implementations have a shm_use_phys optimization which forces the kernel to wire up memory pages used to back SysV segments. This increases performance by not requiring the allocation of pv entries for these pages and also reduces memory pressure. Most serious users of PostgreSQL on BSD platforms use this well-documented optimization. After switching to 9.3, large and well optimized Pg installations that previously ran well in memory will be forced into swap because of the pv entry overhead.

I don't see your comment on the blog (maybe it has to be approved?), but the same issue was raised here during review of the patch. The concern was mostly blown off (most PG developers use Linux instead of BSD, that might well be part of it), but if you had some numbers to back up your post, the -hackers list would definitely be interested. Ideally, you could give numbers and a repeatable benchmark showing a deterioration of 9.3-post-patch vs. 9.3-pre-patch on a BSD. If that's too much work, just the numbers from a dumb C program reading/writing shared memory with mmap() vs. SysV would be a good discussion basis.

http://fedora.12.n6.nabble.com/Fedora-causes-laptop-to-overheat-td2406515.html

I've had this experience myself with the RHEL-family distros (RHEL6, Fedora 16, CentOS 6). On some models they don't seem to run the system fans correctly, the kernel generates a lot of CPU temperature warnings, then the system stops working (sometimes permanently). Actually, I think this problem holds for most Linux distros that are not based on Ubuntu (which runs fine on the same systems).

Mono can generate a normal, runs-without-Mono, Windows .exe executable from your C#, but I get the impression that generation of a (native) .dll can't be done, even with Mono.

I'd recommend that you start learning Python. I moved away from PHP to Python in late 2008 and have NEVER, even once, looked back. Its just a better engineered language and the community is more deliberate and professional. SQLAlchemy is the best database library/ORM ever! And there are plenty of web frameworks to choose from (start with Flask or Pyramid).

Here are some thoughts from 2008 that got me moving away from PHP towards python. The python web community has grown a lot over the last few years, so my comments about Python being hard to get started in can be considered somewhat deprecated:

http://old.nabble.com/Creole-is-Dead,-long-live-Python!-p20488959.html
http://propel.tigris.org/ds/viewMessage.do?dsForumId=1093&dsMessageId=88191

Finally, Python is much more general purpose than PHP, so the Python skills you learn while doing web development can be put to use in other programming areas (I do a lot of scripting and data manipulation with Python).

There are two ways in which a user can "escape" from your application, namely through the windowmanager and through keyboards shortcuts handled by X or the operating system. Since everybody can choose their own windowmanager, the only solution is to replace it with your application which will then run fullscreen. Exiting the application should logout the user in order to revive their own windowmanager. Many windowmanagers have a --replace option; you should mimic that.

The other escape is VT switching using the CTRL+ALT+Fx keys. This thread provides some startiong points on how to achieve that:

http://old.nabble.com/How-to-disable-ctrl-alt-Fn--td14994350.html

Hope that helps. You'll never get it totally secure as long as the users are using their own accounts; as long as they can run other processes than yours, they can do whatever they want.

they were the one major player unable to handle a necessary security task.

I don't know "unable" means in your world, but it my world, it means "not able to be done." Were they slower than others? Yes. Were they the last one? No. Depending on who you consider "a major player", they weren't the last. If you deal with servers, Redhat and Ubuntu also patched the same day. MS only patched 3 days before Apple.

• Ubuntu: September 9, 2011
• Apple OS X: September 9, 2011
• Redhat: September 9, 2011
• FreeBSD: September 6, 2011
• MS: September 6, 2011
• Google Chrome: September 5, 2011
• OpenBSD: August 31, 2011
• Mozilla: August 31, 2011
• Debian: August 31, 2011
• Android: no date
• iOS: no date
• WP7: no date
• BBM: no date

> I am fed up reporting bugs to KDE4, because the general attitude is that nothing is broken and that
> as a user one should adapt to KDE4's behaviour.

That was the reaction by a particular prominent KDE dev when people told him to make KDE 4 like KDE 3 without quantifying and issues or actionable items. Whenever something concrete is mentioned, people like myself jump on it, triage, and file bug reports. Of course, filing a bug report or feature request should have been the first point of contact for the unsatisfied user.

> The most annoying thing for me is the total nonsense of system monitoring, which was perfect
> in KDE3, where you could adapt values, drag&drop sensors, adapt individual colors and select
> every imaginable sensor and put it into the panel.

Please speak up here:
https://bugs.kde.org/show_bug.cgi?id=172312

> These days you have very, very limited options, no chance to integrate a remote host via
> ssh, have a sensible readout of stuff like network throughput. These graphic representations
> are no more than estimates and basically useless for true monitoring.

> Oh, yes, I reported this as a bug and the resulting "discussion" was what put me off KDE4 for good:
> http://old.nabble.com/-Bug-216002--New%3A-Useless-display-of-system-load-(and-network-usage)-in-widget-td26502388.html

That looks like productive discussion. Why would that put you off? The devs were very helpful.

Someone already mentioned this. I'll paste what I said above there (and it's backed up by your second link too, see the section "Sharing Notes"):

From what I know about git-notes, they are a relatively new concept and aren't very well supported. Apparently they don't survive being pushed and pulled by default (that's worse than it may seem -- it isn't sufficient for me to ensure they are pushed; everybody who takes a copy of the repo has to as well).

Integrating one VCS persistently with another relies on storing foreign VCS data in the metadata of the primary system -- if the primary system loses the metadata you are hosed. So for now, using Bazaar (or anything else) as a persistent Git client doesn't work, despite the best efforts of the Bazaar folks (who wrote bzr-git). I hope that one day git-notes is mature enough to support this, but it seems like it would require a backwards-incompatible change to the Git system.

From what I know about git-notes, they are a relatively new concept and aren't very well supported. Apparently they don't survive being pushed and pulled by default (that's worse than it may seem -- it isn't sufficient for me to ensure they are pushed; everybody who takes a copy of the repo has to as well).

Integrating one VCS persistently with another relies on storing foreign VCS data in the metadata of the primary system -- if the primary system loses the metadata you are hosed. So for now, using Bazaar (or anything else) as a persistent Git client doesn't work, despite the best efforts of the Bazaar folks (who wrote bzr-git). I hope that one day git-notes is mature enough to support this, but it seems like it would require a backwards-incompatible change to the Git system.

That's all ready there.

[citation needed]

I am specifically referring to names in the kernel source tree using conflicting cases such as:

include/linux/netfilter/xt_connmark.h
include/linux/netfilter/xt_CONNMARK.h

This requires that the kernel source be stored on a case insensitive file system, and will not work with Cygwin, nor with the default filesystem for OS X.

Examples:
Local uncommitted changes, not checked in to index with gitk
Kernel 2.6.20 File Names Case Sensitivity
The Linux kernel needs a case sensitive filesystem
Another LFS newb is stuck: Linux API headers won't install

etc.

As a server? Not a lot of people. As a client? I can think of plenty who would want to be able to transfer things to and from a Windows share.

Somebody stop me if I'm wrong, but isn't there such a thing as GPLv2-licensed libsmbclient code? It may not be the latest and greatest but it ought to serve for that purpose.

Either way, Apple wasn't planning on letting people modify the version of CIFS they shipped, or contribute fixes back to the Samba tree, so no real loss there. Long story short, we learned something about Apple's ideology and nothing more.

Wrong : "Apple has been updating and hardening a branch of the Open Group's DCE/RPC library. We'd decided to share
these changes with the community at large and will continue to invest in modernizing and advancing this
code base. The goal is to establish a common, authoritative DCE/RPC codebase that everyone can leverage
or contribute to, under very liberal terms.

We have published Apple's contributions at http://www.dcerpc.org./ Please check out the web site for any
more details. We are looking for someone to port it to the various Linux SMB implementations.

Regards,

James Peach and George Colley
Apple"

> I think you meant renaming KTron to KSnakeDuel.

http://old.nabble.com/RFC:-Rename-KBattleShip-and-KTron-td27280141.html

This problem was SOLVED by Dennis and Van Horn back in the 1960s, it's called capability based security. You can read more here: http://old.nabble.com/On-the-Spread-of-the-Capability-Approach-to5608409.html

The concept is simple, every process has a list of capabilities handed to it. It doesn't get to do anything not on the list.

It would be fairly easy to make sane default lists and still have a very usable computer.

Intel's compiler is actually one of the best optimizing compilers out there (when it doesn't detect an AMD processor and not bother doing the optimizations...).

I'll second that, here's an example from the Octave mailing lists:

To conclude, on my computer, for this test, Octave is approximately as fast as C, gfortran is a little bit faster and ifort is 10 times as fast.

For scientific computing it's tough to beat ifort on intel iron.

http://www.nabble.com/CARP-failover-behaviour-td3490125.html

As I mentioned, it looks like an address book server is near: http://www.nabble.com/Darwin-CardDAV-Server-to25243546.html#a25243546

Ok, I know I said I was out, but I'm hoping that the conversation is now actually moving in a direction instead of going in circles.

The MS-PL does not allow you to require that derivative works include the source code. I consider that a restriction.

I see no such restriction on the rest of the work that is not under the MS-PL. You are upset because the MS-PL code retains its license?

It is quite impossible to be incompatible with the GPL without also doing pretty much what it does, which is remake all the linked code with it's own license.

No, you have it wrong. See here:

Section II: Compatibilities and incompatibilities with other OSI licenses: Source code distribution breaks down into two areas: Relicensing of MS-PL code and redistribution of MS-PL code with other code that is licensed under a different license.

                  Can MS-PL code be redistributed under a different license?:

No. The license states that "If you distribute any portion of the software in source code form, you may do so only under this license..." This restriction is similar to the restriction in the Mozilla Public License that states "You may not offer or impose any terms on any Source Code version that alters or restricts the applicable version of this License or the recipients' rights hereunder." The MS-PL license explicitly prohibits relicensing of the original licensed code under a different license, regardless of whether the original code is redistributed in whole, in part or as part of a different piece of software.

                  Can MS-PL code be redistributed in combination with other code that is licensed under a different license?

As long as the original MS-PL licensed code is redistributed under the MS-PL license, then the MS-PL places no restrictions on combining MS-PL code with other code that is licensed under another license. Licenses that prohibit the distribution of code under any terms other than the terms of that license will not be compatible with the MS-PL.

Otherwise a GPL plus linking exception would work to allow the MS-PL code to be absorbed into a GPL system.

I'm not really sure what you mean by "GPL system". The linking exception is there so that you can use the gcc compiler, not to create a "GPL system", whatever that means.

It seems that ASLR of some form or another has been enabled by default in Linux since 2.6.12. [0] Also, IUC compiling code with gcc's -PIE flag helps.

I have a PaX + grsecurity enabled server at home. It'd be *really* nice if the gdb folks could make debugging a possibility under that configuration. Not having stack traces or being able to set breakpoints [1] is a bitch! :)

[0] http://www.nabble.com/Edgy-and-Proactive-Security-td4695373.html
[1] Not being able to set breakpoints is probably something that I can fix with a little Googling.

Weird, because Debian moving away from bash to dash for exactly the same reasons.
http://www.nabble.com/Making-init-scripts-use-dash-td4458217.html

No, it would be "weird" if they moved from bash to python for the same reason.

Weird, because Debian moving away from bash to dash for exactly the same reasons.
http://www.nabble.com/Making-init-scripts-use-dash-td4458217.html

Jim Pinkerton asked me to post this message from Microsoft:

Sincere apologies, but wanted to confirm that there is an issue with NT Domain support in Windows 7. We're trying to expeditiously track down exactly the issue(s), but the short of it is I wouldn't spend time trying to get this functionality to work. We'll get some sort of official notice out shortly (and I do mean shortly).

Jim Pinkerton
Microsoft

There still hasn't been a fix.

My guess: Microsoft made the process of joining a domain more LDAP based and reliant on Active Directory. Still, I just hope this "bug" is fixed.

Go ahead, suggest Java. I dare you. (...) There are a few zillion issues to work out, but I'd endorse this approach. The problem is that this hasn't happened and, if history has taught me anything, it wont happen

OK, I'll do it and suggest Java as a good proof of concept. Right now, you can load and run a signed wrapper applet that loads a native .dll or .so (depending on what system you're on). You can provide a user with a web page that contains icons with native applications (using Applets) configured for his system (web-based configuration). Sure, you will need to provide DLLs, various Linux .so's and libs for OSX (depending on what you want to support), but you have the freedom and performance of C/C++/whatever and the comfortable way of delivering/accessing/configuring/updating your applications over the web with a choice of keeping data on an external server or locally. Something like this has been done before: SANE, JNI and Java all in an applet. The Windows-centric alternative is already very popular (and notorious): ActiveX is being used for web-hosted native applications like virus scanners (and viruses).

Now all we need is to replace the JRE with a simple cross-platform browser plugin that provides rudimentary functions to download and execute native code, but in the mean time, going through JRE/JNI is feasible (with a web-hosted .exe being a crappy alternative for various reasons). People just need to wake up and stop building stuff that runs at a felt 1/100th native speed. I have my hopes that the current popularity of Netbooks will get some developers to take a closer look at application performance again - because Firefox is extremely slow on an Atom CPU and it destroys the "netbook with web apps" concept.

Xen supports this feature since Xen 3.3, it is called CPUID: http://www.nabble.com/Xen-3.3-News:-3.3.0-release-available!-td19106008.html No real breakthrough here...

Looks to me like Xen supports migration between different CPU models, not entirely different CPU manufacturers. So yes, there is a breakthrough here.

Xen supports this feature since Xen 3.3, it is called CPUID: http://www.nabble.com/Xen-3.3-News:-3.3.0-release-available!-td19106008.html No real breakthrough here...

Yes, now go away.

• Package managers are evil. (because someone could possibly provide a repository with software that isn't free-as-in-fsf)
• Hurd vs. Linux.
• GPLv3 is "similar is spirit" to GPLv2. (The anti-Tivo stuff is an entirely new class of restriction.)
• AGPL makes sense. (put it behind a proxy)
• It's possible to make components that are themselves free-as-in-speech and yet can't be used in a non-free-as-in-speech system. (you may not speak in support of censorship...)

* Note: assert(RMS == FSF) for some of these, I believe that's an entirely reasonable assumption.

Say "Thank you, Nabble."

nabble.com has this little treat: http://www.nabble.com/help/Answer.jtp?id=25 I wonder if they realize that the average user has a "standard" password they use everywhere. If so, then they are knowingly phishing. If not, they're morons. As you might imagine, I decided not to use my "standard" password when registering on their site. Am I going to remember it the next time I log in? Probably not. Oh well.

But most of the performance tricks lose their advantages with FUSE

Why? Current results show that a FUSE file system can be even faster than kernel file systems, e.g. ext3:

Some write speeds from http://www.nabble.com/Re%3A-Porting-Zfs-features-to-ext2-3-p18722897.html

tmpfs: 975 MB/sec
ntfs-3g: 889 MB/sec (note, this FUSE driver is not optimized yet)
ext3: 675 MB/sec

In many ways, Kontact is a great PIM. In my experience it seems faster and more polished than Evolution or Thunderbird/Sunbird. Unfortunately, its IMAP support is a bit clunky. According to the one of the devs, until KMail has been moved to the Akonadi back end it is impossible to search across multiple IMAP folders (see http://www.nabble.com/Is-it-possible-to-search-multiple-IMAP-folders-in-a-single-search--td16188937.html ). With 5+ IMAP accounts, it's extremely convenient (necessary?) to define a search folder, call it "Inbox", that polls all IMAP Inboxes for new mail. The same applies for sent mail, etc. It's likely not an issue for most users, but it's something that works flawlessly in other full featured PIM/email clients. For now I'm stuck using slower, uglier PIMs because of a lack of basic IMAP search functionality in KMail. Until it's resolved I'd hesitate to call Kontact "streets ahead" of either Thunderbird, Evolution, or Outlook.

"I deleted the article after a highly concerned late-night phone call from Mike Godwin."

Also, Check this out.

When it's completely painless and everything "just works" I might agree with you.

As for Debian, it looks like unstable firewire stack implementation (JuJu) handles the security issues. However, that same article suggests that Lenny (the next version of Debian) will probably be released with the vulnerable, stable stack because it has more compatibility.

read it , understand it ... then reply.

http://www.nabble.com/prng-and-a-fix-wich-should-(not-)-happen..--to15399833.html