Slashdot Mirror

On performance, they are comparable. (Intel's compiler beating both of them quite handily)

On design, clang is superior because of its modular design. Afterall the LLVM project was designed with the sole intention of replacing GNU GCC toolchain. Historically FSF had an negative opinion on modularity (esp w.r.t plugins) when it came to the gcc toolchain ( http://lwn.net/Articles/301135/ ) and the llvm project has no such requirement, freeing them up from a design POV.

Thats about a tweet sized answer as you can get for such a broad question :-P

Back then, there were two DNS servers out there:

1. BIND, which was horribly insecure and one of the more significant cause of remote root access security holes
2. DJBDNS, which was and by and large is secure, but had a weird maybe-not-open license and lots of quirks

LWN has a good article from that era to give people an idea how limited choices were with open-source DNS servers. Since then, we got Unbound and NSD, PowerDNS, and (shameless plug warning) MaraDNS (there are also a lot of DNS server projects which never were finished or were abandoned years ago, such as OakDNS, Dents, Posadis, etc.)

The idea behind DNSSEC is that is is, within a margin of error (I'm already awaiting a somewhat pedantic correction from a neckbeard), it is the HTTPS of DNS: It makes it impossible (cue neckbeard pedantic correction) to spoof a DNS reply. DNS without DNSSEC is like HTTP without HTTPS: There are security issues where an attacker can make someone go to the wrong web site.

(Yes, I am aware of DNScurve. I'm also aware that, like Esperanto, the best idea doesn't always win--or even get implemented in a mainstream DNS server)

(Slashdot: 2001 called and wants its lack of Unicode support back. Why can't I use use smart quotes or real em dashes in my replies?)

Late followup to this. It is non officially planned and Kristian is working on it. And if he is working on it, it should arrive by the time Wayland is slated to take over from X.org.

A libwayland application may start up a proxy compositor on the machine (server, appliance, closet PC in your example) and blit the compressed damaged regions over the network. Or an RDP (or SPICE, VNC) server could offer the proxy compositor (even through SSH).

He also has commented on examples of a rolling hash algorithm to instruct the client to reposition damaged regions vs re-blitting their contents.

Now that the 1.0 specification has been released, I hope to see others helping out in the area of remoting. Nobody's going to deny that Wayland can't do everything X11 can do today, but they're also not positioning Wayland to replace X11 _today_.

Debian wiki on the subject http://wiki.debian.org/systemd

Also some extract from discussion http://lwn.net/Articles/452865/

So the minimum requirement is that you can delete all the keys.

Wrong. There is no requirement that you *explicitly* can enter UEFI Setup Mode. The system vendor MAY allow such an explicit option, but the MINIMUM requirement is that he MUST allow Setup Mode to be entered by deleting all keys.

Read what you quoted again, please:
1) It SHALL be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK.
2) This MAY be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), WHICH puts the system into setup mode.

So the owner of the system can ALWAYS enter setup mode. He may have some direct way to do that, but he can ALWAYS delete the key databases, which will cause the system to go into UEFI Setup Mode.

"If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off."

So when you delete the keys, SecureBoot is turned off.

Correction: When you delete the keys the system enters Setup Mode. If you choose to exit the automatically invoked setup mode WITHOUT entering a new platform key, THEN secure boot is turned off. Which makes perfect sense as there are now no keys in the firmware which could validate anything.

There's also an option to always put the Microsoft key back in place. But that's it.

No, you can enter ANY key into the Platform Key database. From http://lwn.net/Articles/447381/ : "Before a PK is loaded into the firmware, UEFI is considered to be in "setup" mode, which allows anyone to write a PK to the firmware. Writing the PK switches the firmware into "user" mode. Once in user mode, PKs and KEKs can only be written if they are signed using the private portion of the PK, though KEKs can be freely written during setup mode. Essentially, the PK is meant to authenticate the platform "owner", while the KEKs are used to authenticate other components, like operating systems."

At no point does it guarantee that you can enter an arbitrary key and keep secure mode on.

And you are wrong. The PK (Platform Key) is the "owner" key. You can enter your own key if you like.

Which is basically what I said.

But you were mistaken.

And "possible" can be provided by means of, say, a supplied disk available at extra cost from the manufacturer that has to be inserted for such action to be taken at all.

Lip service.

So, basically you are spreading FUD: *Fear* that it may incur extra costs, *uncertainty* because you choose to disregard facts and present your own speculation and conjecture as facts, and finally *doubt* as to the "real" intentions behind secure boot.

The Moblin alpha and beta releases booted in about 5 seconds, on a single-core Atom netbook, to a full linux desktop.

The alpha was mostly Fedora packages, the beta had a surprisingly sensible UI for the class of devices it was targeting, and would have done well for tablets, I think.

I wish that I knew how to make my computers do that again. You may talk about instant booting from ROM, but show me any combination of modern hardware and software that approaches the speeds of Moblin.

"It's not about booting faster, it's about booting in five seconds." Sigh...

Tizen is also seriously targeting the automotive market. The old carputer concept has been reborn under the initialism "IVI", for "In Vehicle Infotainment", and lots of ODMs seem to be interested in getting a piece. IVI industry types are the major backers of big kernel changes like the controversial new AF_BUS.

Exactly, its meant to deal with a Flash Translation Layer

>whenever I tried to pull a file remotely the connection would grind to a halt

That's bufferbloat or a poor queuing discipline.

fq_codel - http://lwn.net/Articles/504005/ would make the connection behave better.

Linux, bittorrent, tcp/ip, html are just a few examples that have nothing to do with corporations in their inception.

Inception != Success. And do not underestimate the contributions of big corporations to open source. The original premise is not without merit. Big corporations have been instrumental in the success of most if not all major open source projects. The only way you can claim that big companies have nothing to do with these technologies is if you are willfully blind to the facts. Just because the big companies are not always the ones that start these projects doesn't mean they aren't important to the success of the projects.

Linux was started as a project by one guy but have no illusions that it would have gotten where it is without the help of big corporations and the talent they possess. Need proof? How about pretty much every major tech company including Red Hat, Intel, IBM, Novell, Microsoft (yes Microsoft), Texas Instruments, AMD, Oracle, Nokia, Google, Samsung, and a whole bunch more having made significant contributions to the linux source code.

HTML was started at CERN which is a pretty big organization (effectively a non-profit company) and would not have gotten to where it is without the help of countless companies. TCP/IP was heavily influenced by Xerox PARC as well as IBM, AT&T and DEC not to mention DARPA. AT&T developed the TCP/IP stack for unix and put it into the public domain.

Hadn't heard about AF_BUS before...
I found the rationale, and a summary of the argument against.

I get that doing multicast in userspace isn't optimal, but I'm a bit mystified what people are doing with D-Bus that would require any kind of performance. Wasn't D-Bus supposed to be a simple pub-sub system for notification of events and the like?

Hadn't heard about AF_BUS before...
I found the rationale, and a summary of the argument against.

I get that doing multicast in userspace isn't optimal, but I'm a bit mystified what people are doing with D-Bus that would require any kind of performance. Wasn't D-Bus supposed to be a simple pub-sub system for notification of events and the like?

However, there's another more important point: what other obvious things didn't we really bother to check?

It occurs to me that we have a similar meme: Given enough eyeballs, all bugs are shallow, however it can be surprising how long a nasty bugs can survive in code that many people look at (unfortunately). Checking is not as exciting as looking for (or writing) something new.

That may be so if you see it as a dialogue between two equal strong-willed technocrats; but if you read this LWN article Statistics from the 3.7 development cycle, there were almost twelve thousand changesets submitted to the previous, 3.7 kernel.
The process is hierarchical because Torvalds cannot "go 11 on the douchebag scale" on all of the 11815 patches from 3.6 to 3.7 that were bad, it's not humanly possible. It's a dialogue between one strong-willed technocrat dictator and 1271 technocrat kernel "underlings", some of which are probably also strong-willed and/or douchebags.
So it seems that means he "went 11 on the douchebag scale" as some kind of overreaction to one of his "underlings" for not following sanctioned procedure ("thou shalt not break userspace") and trying to avoid responsibility "the userspace ppl did it wrong".
If it's a hierarchical pyramid of power and responsibility then the people nearer to the top must take more of the responsibility to keep things working right, not say something like "well userspace does it wrong anyway".

But it's humiliating and embarrassing to see happening, like seeing someone be spanked in public. It's not fun for anyone involved or for the bystanders.

more nerd rage

64bit binaries are also larger, meaning that for the same hardware configuration the CPU can cache more 32bit code than 64bit. 64bit binaries also take more RAM, increasing swap times.
This is why I'm running a 64bit kernel with most of the userspace being 32bit, the exception are numerical computation tools (numpy and friends) which live in a 64bit chroot. This is my personal laptop, office computers are fully 64bit.

If you want "the best of both worlds", you have the new x32 ABI which gives you 32bit pointers and the extended 64bit CPU register set:
http://en.wikipedia.org/wiki/X32_ABI
Gentoo is already publishing release candidate stage tarballs for x32, official support should be coming pretty soon..

PS: Parent is also me, I forgot to login.. sorry about that.

It's not the instruction set, it's the differences in boards.

Ya, I don't get that. I'd ratther have a bunch of board files, than a single SoC file. Seems if you get rid of the multiple board files then you need multiple device tree files. Instead of nice, tightly focused board files just for that board you need a more bloated, generalized kernal to parse a device tree for that board. To me, Linux on ARM means embedded systems and every byte saved is a penny earned. I don't want to bother with parsing a device tree file! Am I missing something?

It's not the instruction set, it's the differences in boards.

he thinks things like the BSD license are immoral

That's completely false. RMS has endorsed the use of the BSD in the past, and he has always considered them Free.

he says in at least one of his essays that he believes non-open sourced code should be illegal.

Either provide a link or stop defaming the man.

I'm actually rather surprised at how hard it is to get specific information on the ARM64 instruction set at this point. [...]

The ARM architecture supports physical address extension (PAE) with a 40-bit (1 TiB) physical address space. On ARM, as on x86, PAE potentially allows hundreds of GB of RAM but only 2 GB per process. Under Android, applications can share a process, but different publishers' applications run in separate processes. Though PAE-intolerant drivers for desktop peripherals have forced Microsoft to switch off PAE for desktop Windows, 32-bit versions of Windows Server support PAE on x86, as does Linux both on x86 and on ARM. So you might see Android devices using PAE long before they go 64-bit.

Gender arguably is more relevant but seriously... there is no bias against women participating in free software projects. It's literally a sport open to anyone, with as few barriers as you can imagine. Age, gender, skin color, origin, perhaps the only filter that reduces diversity is the need for reasonably fluent English.

And still, the number of women in our communities is extremely low. That means the detailed technical world of software appeals to fewer women than it does to men.

Are you sure there are no barriers to participation by women? Have you, for example, asked any women who have tried to participate? A quick internet search suggests that those few women who have tried out participation in Open Source projects found that there was a significant element to the experience that wasn't pretty. That is plenty to discourage women from taking part.

Broadcom broke down and released open-source drivers for Linux back in Sept. of 2010. See LWN. They then joined the Linux Foundation in early 2011 (reference).

Their reputation for being open-source-hostile is well-deserved, but not entirely up-to-date. I can understand why people continue to avoid them, but it may not be strictly necessary any more. I haven't researched how well their open-source drivers work, because I haven't needed to in the brief period of time that it's been an option, so that may or may not be a factor as well.

Most binary kernel modules are assumed to be 'not derived works' ... just 'cause nobody wants to argue about every little thing.
This assumption nature of derived was later refined and codified by the use of EXPORT which defines the Kernel ABI which can reasonably be presumed is common to to non-Linux kernels and GPL_EXPORT which defines a 'GPL ONLY' Kernel ABI which one would call specific to Linux. The presumption is then that a kernel module using a GPL_EXPORT feature is being *written for* Linux and not being *ported to* Linux.

In other words by DMA-BUF implies that NVIDIA is writing a driver *for* and not porting an existing driver (from Darwin or Solaris for example).

Here is a discussion of a similar situation http://lwn.net/Articles/73121/
Here one of Linus original statements on kernel modules: http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html
And here is a more recent one: https://lkml.org/lkml/2003/12/3/228

My (hypothetical) opinion is that if NVIDIA where to show their driver on OSX and that the use of DMA-BUF was an insignificant architectural change then the would likely prevail as a non-derived work should they choose to go forward. If however the use of DMA-BUF would be a signficant architectural change then the non-derived argument would be not be easy to make.

See: http://lwn.net/Articles/154602/ By using EXPORT_SYMBOL_GPL the kernel's linker simply prevents any kernel module NOT marked as GPL, which is using EXPORT_SYMBOL_GPL'ed functions, from loading. EXPORT_SYMBOL is not magically allowing non-GPL code, it just means that people can play ignorant and pretend they didn't know better. IANAL

There's an old, politically incorrect, cartoon with a husband freaking out in a car while his wife is driving the wrong way into oncoming , and saying, "I'm not going the wrong way... THEY are going the wrong way". Lennart Poettering wrote systemd, which is broken on machines with a separate /usr (without initramfs). Like the wife in the cartoon, his reaction is "My software isn't broken... the machines my software won't run on are broken. Repartition and reformat your machine.".

If that had remained strictly a Redhat-ism, nobody else would've complained. However, udev has been hijacked into the systemd tarball https://lwn.net/Articles/490413/ Because of the shared code with systemd, udev shares systemd's brokenness on machines with separate /usr, even if you're not running systemd itself. That's the vast majority of linux systems.

As the infomercials say... "But wait, there's more". Lennart Poettering has made no secret of his desire to do away with standalone udev. See
http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html Basically, if you want to use udev (required by the vast majority of linux machines) you'll one day need to switch to systemd.

There are scattered efforts to run systems on mdev, bypassing udev altogether.
https://github.com/slashbeast/mdev-like-a-boss#readme
https://wiki.gentoo.org/wiki/Mdev
https://wiki.gentoo.org/wiki/Mdev/Automount_USB

Opinion?

You can find a lot of details in the txt file: https://lwn.net/Articles/518719/

Hacker News has "News for Startups". Many /. articles show up there first. The community has, generally, far fewer commentators and much less humor. Expect to see a lot of stories about new javascript libraries, and blog posts from random idio^H^H^H^H"entrepreneurs". Tag it "RTFPressRease"

People tell me good subreddits exist. I'm not sure I believe it. Tag it "RTFImageCaption"

Linux Weekly News comes with a free neck adjustment to facilitate looking down on things with fewer freedoms. Tag it "RTFLKML"

Ars Technica, and Wired are both brought to you by their corporate overlords. Hard to complain about the reporting, it's sanitized but not awful. There's no community to speak of at either. It gets tagged for you.

Or you could DIY TFA with a custom RSS feed. But unfortunately I don't think what you're looking for exists outside slashdot, even in its supposed decline. You may get better answers, though, by defining what kind of nerd you are.

You might want this page then:

http://kernelnewbies.org/Linux_3.6

It usually has links to http://www.h-online.com/ http://lwn.net/ and/or Wikipedia which hopefully explains it in a way you'll understand.

The freature was add to Linux kernel in 2.6.21 http://lwn.net/Articles/223185/

Linux has had the dynamic ticks (CONFIG_NO_HZ) feature for a while, but that only shuts down the timer tick when the system is completely idle. There is a new feature in the works named "adaptive tickless", see announcement and a recent progress update, that will also shut down the timer tick when the system is running a single task.

The people working on Wayland have used X11. Indeed, in many cases they are *also* X.org developers. Hell, one of the people working on Wayland is Keith Packard[1], who's been working on X.org since longer than I've been using Unix. Indeed, he's been working on X11 since before many of us had even used a computer, indeed for anyone younger than 24 make that "since before you were born". Hence, to say the people who are working on Wayland do not understand X is just a ridiculous argument, and does not suggest the person making that argument has much credibility on the subject.

I'll be honest, I was a little sceptical when I read about some of the design decisions in Wayland. In particular, the decision to move some of the window management to the application (in general, that means the toolkit, like Qt, GTK+, etc) makes me wince a bit, because it will lead to the hung-window-syndrome we know and love from MS Windows. However, the people involved in Wayland know far far far more about the subject than I do (I have no experience of designing or implementing windowing systems), and I'm sure they know a lot more about balancing the various trade-offs for and against all these decisions than most of us.

As for the remote displays. I was initially concerned about that capability too. However, if you look into it, well there's nothing that stops X11 being used with Wayland - indeed X server to render to Wayland already exists. Generally, there's nothing to prevent whatever style of remote display protocol being implemented for Wayland, be that in applications directly or (more sensibly) in the toolkits.

1. Keith Packard on Wayland and X: https://lwn.net/Articles/491509/

sandboxing is just another layer of security, it isnt a silver bullet solution... in fact many times (like in chrome) is used as a excuse to not proper check things and do a more careless development (from the security point of view). all is well until someone finds a way to break out the sandbox (just look at the recent java security problems) and then you can use one of the many holes to hop jump the sandbox and reach the OS.
Firefox mostly dont have sandbox, but have many other proper security checks that other lack, and its secure because of then. Of course sandbox is yet another layer that should exist and they are slowly sandboxing key areas. Its harder because they want to support various OS at the same level where chrome have a full sandbox in windows but a lot weaker one in linux (see https://code.google.com/p/chromium/wiki/LinuxSandboxing and https://code.google.com/p/chromium/wiki/LinuxSUIDSandbox... things might be better when seccomp is enabled by default in chrome)

So yes, sandbox is good, but should not be trusted as the main security barrier in one application, other checks are always needed.

Linux doesn't work completely on brand new hardware!!

It works great on our hardware. We get Linux working on it before we release it. We push the support into the kernel and GCC and binutils and all the other stuff before it becomes an issue.

Apple are hardly going to be focusing on cleaning up Linux's issues.

The problem with mangling is C gives you a symbol like "strcpy", which you might compare for the 50,000 links that have to be made during program load, and have to perform 300,000 character comparisons.

In C++ you get _NSstd__IOSTREAM__55STRING_OPEREQ__STRING__STRING__CHARX__ or some crazy thing. You wind up with 100, 150, 250 character long function names for class foo member 'int bar(int, &int)'. To make matters worse, the above hypothetical was ridiculous: you won't do 300,000 character comparisons because there are only about 20 str* functions, you'll do 60 comparisons (20x3) plus around 50,000 more because of all these functions that don't start with 's' (though there will be a couple thousand that do, but don't start with 'st', adding a few thousand more comparisons). In C++, though, things aren't so friendly...

In C++, you actually wind up comparing, as per our approximated example, _NSstd__ for EVERYTHING in the std namespace. That's 8 character comparisons per symbol (function, overloaded operator, variable, class, class member, etc) in the std namespace--everything in the STL. That once for EVERY symbol in the STL. EVERYTHING under the IOSTREAM class has to compare _NSstd__IOSTREAM__, so each one of those totals 18 character comparisons per member of the IOSTREAM class. That means just to load IOSTREAM you definitely have to do (members_of_iostream^2 * 18 / 2) character comparisons. In the real world, you can do hundreds of thousands or even millions of character comparisons just to load one C++ class member.

It used to take about 14 seconds to load OpenOffice.org on a given piece of hardware. Michael Meeks made that about 1.7 seconds by direct binary linking (i.e. telling the linker that a given symbol was in a given library), avoiding 95% of the character comparisons. It got down to somewhere between 2.5 and 3.5 seconds with just Meeks' PT_GNU_HASH non-standard ELF extension, which adds sorted bucket hashes to the symbol tables to bypass most of the work--it worked so well, in fact, that after publicly discussing the patch on the glibc mailing list as Meeks repeatedly submitted new versions, Ulrich Drepper waited a month and then put his name at the top of the patch and claimed he wrote it (on the same mailing list!).

Meeks had white papers written about this shit. He showed how long it takes C programs to link versus similar C++ programs, explained why, then set out to mitigate the stupidity caused simply by using C++. Current gcc toolchains produce PT_GNU_HASH headers (precomputed ELF hashes) and sort the symbol tables to match the ordering of the hash tables, allowing glibc to basically walk through the binary in a straight line. This eliminates the CPU overhead of computing hash values (never mind character comparisons, we're doing a ton of math) and puts everything in a straight line so PREFETCH instructions and just built-in automated CPU prefetching can reasonably eliminate CPU cache misses--which makes things REALLY fucking fast. Loading a C++ program on Linux is now roughly half as fast as loading an architecturally equivalent C program, which is an improvement over the 10x longer it used to take to load C++ programs.

You can see a bunch of shit at http://lwn.net/Articles/192624/ for the executive summary. Sorry the writing's so poor; I need to not write technical column articles like I write slashdot posts.

https://lwn.net/Articles/491509/

https://lwn.net/Articles/491509/

Wayland is designed to fix a lot of the problems that X has. X, for historical reasons, does a TON of things. It has network transparency, it's responsible for input, for setting up the graphics card's memory and registers, drawing various primitive shapes, font rendering, etc.

But today 99% of the time people don't use the network transparency stuff in X, they run locally. But all sorts of memory has to be shuffled around. X mandates all sorts of bitmap formats that must be supported. Today the kernel, through KMS, can setup the graphics card. We have libraries like Cairo to draw basic shapes. Then there are all sorts of weird things that have been hacked into/onto X to support common features like resizing and rotating your desktop.

Wayland basically started with a blank slate. The kernel can setup the video card, so it won't do that. Most people don't use network transparency, so it doesn't do that (you can run an X client on Wayland, for when you still need the feature). The GUI toolkits and OpenGL libraries already draw everything, so it doesn't do that stuff.

LWN had an article from two years ago about what Wayland set out to accomplish. Things may have changed since there, here are two updates from LWN describing Wayland earlier this year.

This is a far better description of Wayland than what I've read to date either here on /. or even on Wayland's own website. Thanks for explaining it so succinctly.

Question - is Wayland support then going to be something that the designers of the various window managers will have to implement, or will the various kernel teams, like Linux, BSD et al have to implement them? Or do the creators of Wayland have to port Wayland to all the different kernels to make sure that they can make use of all their kernel mode services?

Wayland is designed to fix a lot of the problems that X has. X, for historical reasons, does a TON of things. It has network transparency, it's responsible for input, for setting up the graphics card's memory and registers, drawing various primitive shapes, font rendering, etc.

But today 99% of the time people don't use the network transparency stuff in X, they run locally. But all sorts of memory has to be shuffled around. X mandates all sorts of bitmap formats that must be supported. Today the kernel, through KMS, can setup the graphics card. We have libraries like Cairo to draw basic shapes. Then there are all sorts of weird things that have been hacked into/onto X to support common features like resizing and rotating your desktop.

Wayland basically started with a blank slate. The kernel can setup the video card, so it won't do that. Most people don't use network transparency, so it doesn't do that (you can run an X client on Wayland, for when you still need the feature). The GUI toolkits and OpenGL libraries already draw everything, so it doesn't do that stuff.

LWN had an article from two years ago about what Wayland set out to accomplish. Things may have changed since there, here are two updates from LWN describing Wayland earlier this year.

This is a far better description of Wayland than what I've read to date either here on /. or even on Wayland's own website. Thanks for explaining it so succinctly.

Question - is Wayland support then going to be something that the designers of the various window managers will have to implement, or will the various kernel teams, like Linux, BSD et al have to implement them? Or do the creators of Wayland have to port Wayland to all the different kernels to make sure that they can make use of all their kernel mode services?

Wayland is designed to fix a lot of the problems that X has. X, for historical reasons, does a TON of things. It has network transparency, it's responsible for input, for setting up the graphics card's memory and registers, drawing various primitive shapes, font rendering, etc.

But today 99% of the time people don't use the network transparency stuff in X, they run locally. But all sorts of memory has to be shuffled around. X mandates all sorts of bitmap formats that must be supported. Today the kernel, through KMS, can setup the graphics card. We have libraries like Cairo to draw basic shapes. Then there are all sorts of weird things that have been hacked into/onto X to support common features like resizing and rotating your desktop.

Wayland basically started with a blank slate. The kernel can setup the video card, so it won't do that. Most people don't use network transparency, so it doesn't do that (you can run an X client on Wayland, for when you still need the feature). The GUI toolkits and OpenGL libraries already draw everything, so it doesn't do that stuff.

LWN had an article from two years ago about what Wayland set out to accomplish. Things may have changed since there, here are two updates from LWN describing Wayland earlier this year.

This is a far better description of Wayland than what I've read to date either here on /. or even on Wayland's own website. Thanks for explaining it so succinctly.

Question - is Wayland support then going to be something that the designers of the various window managers will have to implement, or will the various kernel teams, like Linux, BSD et al have to implement them? Or do the creators of Wayland have to port Wayland to all the different kernels to make sure that they can make use of all their kernel mode services?

QuickBooks has scary limits built in. They suck you in with the entry price, but at some point if your business is successful and actually has multiple customers, you will exceed the built-in limits. Then it's time to upgrade. Not "it's time to think about upgrading" you have to upgrade right away because you have exceeded the limits and the version of QuickBooks you bought won't work any more. Expect to spend several thousand dollars.

LWN documents this happening.

It's a pretty reasonable open source license, actually. It is basically a BSD license, plus a patent grant, plus a mutually assured destruction clause regarding patent suits....

Let's put that claim to rest right now. It's the opposite of reasonable. Instead the Ms-PL is intentionally designed to divide the open source community. See this informed discussion.

Have you considered just paying a bookkeeping service to do payroll for you? As a small business owner, I recommend doing that. It's especially true if you need to do anything like garnishments. I think you'll find the cost to have them do just your payroll is a no brainer.

Second, depending on your business structure, what you most likely need to generate out of your financial software is a P&L - profit and loss statement. When it comes tax time, your tax person should be able to use that regardless of which system it came from. Most accountants know how to work with Quickbooks though, and if you use Quickbooks you can just do a simple export and hand that file over to them. You'll get the best tax analysis that way.

I think if you have a simple business, then you probably have a lot of options. If your business is planning on expanding rapidly with lots of complicated accounting or inventory management or job costing or a myriad of other things, you really might want to consider Quickbooks.

See this article from LWN in 2009 on the state of open source accounting systems. It's probably not that out of date: http://lwn.net/Articles/314577/

Wayland is designed to fix a lot of the problems that X has. X, for historical reasons, does a TON of things. It has network transparency, it's responsible for input, for setting up the graphics card's memory and registers, drawing various primitive shapes, font rendering, etc.

But today 99% of the time people don't use the network transparency stuff in X, they run locally. But all sorts of memory has to be shuffled around. X mandates all sorts of bitmap formats that must be supported. Today the kernel, through KMS, can setup the graphics card. We have libraries like Cairo to draw basic shapes. Then there are all sorts of weird things that have been hacked into/onto X to support common features like resizing and rotating your desktop.

Wayland basically started with a blank slate. The kernel can setup the video card, so it won't do that. Most people don't use network transparency, so it doesn't do that (you can run an X client on Wayland, for when you still need the feature). The GUI toolkits and OpenGL libraries already draw everything, so it doesn't do that stuff.

LWN had an article from two years ago about what Wayland set out to accomplish. Things may have changed since there, here are two updates from LWN describing Wayland earlier this year.

Wayland is designed to fix a lot of the problems that X has. X, for historical reasons, does a TON of things. It has network transparency, it's responsible for input, for setting up the graphics card's memory and registers, drawing various primitive shapes, font rendering, etc.

But today 99% of the time people don't use the network transparency stuff in X, they run locally. But all sorts of memory has to be shuffled around. X mandates all sorts of bitmap formats that must be supported. Today the kernel, through KMS, can setup the graphics card. We have libraries like Cairo to draw basic shapes. Then there are all sorts of weird things that have been hacked into/onto X to support common features like resizing and rotating your desktop.

Wayland basically started with a blank slate. The kernel can setup the video card, so it won't do that. Most people don't use network transparency, so it doesn't do that (you can run an X client on Wayland, for when you still need the feature). The GUI toolkits and OpenGL libraries already draw everything, so it doesn't do that stuff.

LWN had an article from two years ago about what Wayland set out to accomplish. Things may have changed since there, here are two updates from LWN describing Wayland earlier this year.

Wayland is designed to fix a lot of the problems that X has. X, for historical reasons, does a TON of things. It has network transparency, it's responsible for input, for setting up the graphics card's memory and registers, drawing various primitive shapes, font rendering, etc.

But today 99% of the time people don't use the network transparency stuff in X, they run locally. But all sorts of memory has to be shuffled around. X mandates all sorts of bitmap formats that must be supported. Today the kernel, through KMS, can setup the graphics card. We have libraries like Cairo to draw basic shapes. Then there are all sorts of weird things that have been hacked into/onto X to support common features like resizing and rotating your desktop.

Wayland basically started with a blank slate. The kernel can setup the video card, so it won't do that. Most people don't use network transparency, so it doesn't do that (you can run an X client on Wayland, for when you still need the feature). The GUI toolkits and OpenGL libraries already draw everything, so it doesn't do that stuff.

LWN had an article from two years ago about what Wayland set out to accomplish. Things may have changed since there, here are two updates from LWN describing Wayland earlier this year.

That sounds exactly like UnionFS or union mounts: http://lwn.net/Articles/312641/, http://lwn.net/Articles/217084/. UnionFS is used in some LiveCDs to allow saving to a ramdisk (which you could dump to a file if you want).

That sounds exactly like UnionFS or union mounts: http://lwn.net/Articles/312641/, http://lwn.net/Articles/217084/. UnionFS is used in some LiveCDs to allow saving to a ramdisk (which you could dump to a file if you want).

In my opinion, it is designed pimarily so that Intel's embedded processors run Android well in the short term. Atom architecture in particular benefits in that some pointer offset calculations are faster when done in 32-bit vs 64-bit. Here are some great discussion links: http://blog.flameeyes.eu/2012/06/debunking-x32-myths http://lwn.net/Articles/503412/

"Sveasoft is a small company which makes its living by selling supported versions of Linux-based firmware for a number of wireless routers. Paying subscribers can download current versions of the firmware, which adds a number of features not normally found on those routers. They can grab updated versions as they become available, and participate in support forums as well.
Sveasoft's products are based on free software - Linux in particular. The company's approach to GPL compliance has raised eyebrows for a couple of years now. One tactic employed by the company has been to terminate support accounts for any subscriber who further redistributes the Sveasoft binaries or source. The GPL says that customers are entitled to that code (for the GPL-licensed portions of Sveasoft's products, at least), and that they have the right to pass it on to others. Sveasoft has responded that, when this redistribution happens, it is no longer obligated to provide future versions of the software. The company has employed various schemes for determining which subscriber has redistributed any particular version, and has been quite aggressive at shutting down accounts.", quoted from http://lwn.net/Articles/178550/

Although this complaint is merely a cry for PHP to receive fixes in its code, I have read on the web that a major issue with PHP has to relate to hashes. According to LWN.net, a denial of service can occur when the hash functions are put into excess which will cause the system to become unresponsive and cause denial of service.

Yes, I do agree with my peers. The largest benefit to PHP is its C-like syntax, and TIOBE.com lists C as the top language followed closely by Java, C++ and then Objective-C, which is C with Smalltalk.