At first, this sounds like the kernel developers have raided LP's "private stash", but it turns out the reason for kdbus is preceeds it - in fact in even preceeds d-bus itself. Specifcally, kdbus is intended to be a alternative version of Android's binder. Android doesn't use d-bus, because it didn't exist (or was too immature) back when it was concieved. While binder is in the staging tree, it'll never be part of the kernel proper for various - some fixable, other unfixable. Binder is not just a hard pill to swallow for the kernel developer, its a spiked ball the size of a fist in a bottle labelled "NOT TO BE TAKEN ORALLY".
There's a NEED for something like kdbus independt of systemd. We needs a new IPC type, like domain sockets, except with reliable multicast and filtering. Linux domain sockets do not support multicast, much elss reliable multicast. Approaches to add this have been tried: Both by directly adding multicast to domain sockets or by adding an ew address family (AF_DBUS), but patches adding that to unix domain sockets have been rejected, as has AF_DBUS.
No one suggesting putting the entire dbus-daemonm and protocol in the kernel with kernel XML parser (and so dbus-daemon will still be needed for authentication and the inital connection setup, but then steps out of the way after that), kdbus is "just enough" to implement an accelerated and robust message bus.
I do admit it sucks that purchases are bound to the system and not to an account, leaving you at Nintendo's whim in a catastrophe, but that having been said I've been one of the lucky ones to get Nintendo's assistance in having my purchases moved to a new system after mine was stolen. The rep was very helpful, and although it was far from trivial (they required a letter, including documentation of the theft, they needed the old and new serial numbers) and good circumstance (My Nintendo account was linked to my Wii, and it apparently it was important that I NOT run the Wii Store app, something i could have not of known in advance; it was fortunate I called Nintendo early in the system setup process) I am very grateful for Nintendo's help in this.
The nouveau driver supports everything from NV04 upwards - NV01 and NV03 (NV02 never made it to production) are very different. In particular, PFIFO (the engine on the card that submits command the GPU) on NV01 doesn't support DMA at all, and NV03 has broken DMA. For that (and other) reasons, if support were desired for these cards, it would be in a separate driver. However such a driver would essentially be of academic interest, since these cards only accelerate simple shapes (like triangles and curves).
That having been said, one of the nouveau developers has done some reverse engineering of the NV01, the finiding of whic hare in the envytools notes.
This is already true under BIOS, since at least the mid 90's. As far back as the 386SL, there been a System Management Mode, which does exactly that. It performs important tasks like checking the processor and shutting it off/slowing it down if its get too hot, and emulating legacy hardware. It interrupts at indeterminate times, for an undetermined amount of time, and it can't be disabled (usually, but you wouldn't want to even if you could). this why "hard" real-time is impossible on x86 platforms.
I've posted this before but it bears repeating here.
I my case, my apartment was burgled, and my Wii was stolen. I bought a new one and called Nintendo. I did not have to re-mail both Wiis like in the story (which would have been impossible, of course). I explained the situation, and I was instructed to write a small letter with the police report and serial #'s of both Wiis. They transferred it.
Now, I admit the certainly not very convenient, but its a far cry from shipping a pair of Wii's to Nintendo.
You should have called Nintendo to explain the situation.
In my case, my Wii was was over a year old, and it wasn't damage - my apartment was burgled and my Wii stolen. (Fortunately I carry renter's insurance). I got a new Wii, called Nintendo explained the issues. I had not yet signed into the Wii Shop channel on the new Wii (which is good, becasue its important to NOT do so) They me send a letter with thep police report and the serial # of the old and new Wii. And sure enough, they moved all my old content to the new Wii.
WEP is "Wired Equivalent Privacy". It wasn't supposed to be very strong - about a secure a regular wired network. However, it wasn't known back then just HOW weak it was. As a stopgap measure, WPA PSK (TKIP) was created. Since it uses the same algorithm as WEP, (RC4), existing equipment could be easily upgraded with just a firmware/software update. A long-term solution WPA2 PSK (AES) was created as well.
WPA-PSK (TKIP) is still far, far better than WEP by many order of magintude, but WPA2-PSK is better, and if all you wireless devices support it (in particular the Nintendo DS DOES NOT, The DSi does, but not for DS games), then that preferred.
Don't confuse ffmpeg with libavcodec. Although libavcodec is part of of the ffmpeg distribution, and is used by many other program (mplayer especially), ffmpeg is more than that.
NFS(v4) would be a lot more accessible if Linux supported more methods than AUTH_SYS and Kerberos. 2 more mechanisms - SPKM3 (TLS-like) and LIPKEY (simple username/password, requires SPKM3)are mandated by the NFSv4 RPC. (SPNEGO and NTLMSSP mechanisms would be nice too). The kernel might have support for them, but userspace GSSAPI support for anything other the Kerberos is poor to nonexistent.
This used to be true, but not anymore. Now there's Server Name Indication - RFC3546, that would allow this. However, OpenSSL (and by extension, mod_ssl) does not support it. GNUTLS does, however (and there's a corresponding mod_gnutls for Apache.
But the damages aren't "punitive", they are "statutory". They aren't intended to punish the infringer, rather the are intended to grant the appropriate relief to the plaintiffs when "actual" damages can't be easily calculated (since no one knows how many works were infringed).
So if the Data Loss Database is a database of all the databases that have had data lost/exposed, if the Data Loss Database itself loses data, dose it list itself?
WINE is an unstable target (in terms of development, not performance), however. Furthermore lots of these MMORPGS have intrusive "anti-cheating" tools (And even among games, they have those obnoxious copy-protection schemes).
IT be nice if they were native, but the chances of game companies writing/porting against a more agnostic target (like SDL) are practically zero.
So at least in the near future, Linux users will happy with whatever little support crumbs we can get. But one day these digital dark ages of DMCA, DRM and Microsoft's monopoly will finally come to an end....
It may, in some sense, be literally true, but Cocmast's statement amount to little more than Equivocation.Keep in mind we impeached a President over the same kind of equivocation, for an issue far less material then Comcast's one.
Which is part of the reason why everyone's so mad - Comcast has been caught with the cigar in the dame, its time for them to come clean (which they should have done even before they were caught).
There's plans on doing that, the reason they didn't do it on pipes and socks is neither socket() nor pipe() has a "flags" argument. So far, there no consensus how to do this - new system calls could be created, but no one wants to wind up with something like Windows API where one has multiple versions of the same call (The...Ex calls) and taking 20 different arguments, half of which are unused. A prctl could be used, but that's racy with multiple threads.
So this is a big problem.
Not suprising, Linux avoid pathname-based security
on
When Not to Use chroot
·
· Score: 1
The Linux developers generally looked down pathname-based security (for what I think are good reasons). That's one of the reasons like SELinux is venerated and AppArmor is snubbed. So this is no surprise. Especially given the VFS and namespace games you can play in Linux (bind mounts, slave mounts,/proc ).
So this is no surpise. chroot() is certainly useful, but not for keep root in jail; use SELinux for that.
Not necessarily; NTFS is both in the kernel AND in FUSE. However, the kernel version is less full-featured than the user-space version (ntfs-3G); because of lack of manpower and that author strict quality control - the old NTFS driver ate filesystems.
That said, I can't see ZFS ever being in the kernel - even licensing problems aside; its a HUGE layering violation. Some say they can do a ZFS without the layering problem; an ambitious project - btrfs exists to try do exactly that. Of course its nowhere near done (currently it'll oops if the filesystem gets full, among other things) - but its one to keep an eye on.
Slashdot Mirror
DH being the Designated Hacker, of course.
...will they be able to certify it as tuna-safe ?
hHe short version: http://lwn.net/Articles/551969/
At first, this sounds like the kernel developers have raided LP's "private stash", but it turns out the reason for kdbus is preceeds it - in fact in even preceeds d-bus itself. Specifcally, kdbus is intended to be a alternative version of Android's binder. Android doesn't use d-bus, because it didn't exist (or was too immature) back when it was concieved. While binder is in the staging tree, it'll never be part of the kernel proper for various - some fixable, other unfixable. Binder is not just a hard pill to swallow for the kernel developer, its a spiked ball the size of a fist in a bottle labelled "NOT TO BE TAKEN ORALLY".
There's a NEED for something like kdbus independt of systemd. We needs a new IPC type, like domain sockets, except with reliable multicast and filtering. Linux domain sockets do not support multicast, much elss reliable multicast. Approaches to add this have been tried: Both by directly adding multicast to domain sockets or by adding an ew address family (AF_DBUS), but patches adding that to unix domain sockets have been rejected, as has AF_DBUS.
No one suggesting putting the entire dbus-daemonm and protocol in the kernel with kernel XML parser (and so dbus-daemon will still be needed for authentication and the inital connection setup, but then steps out of the way after that), kdbus is "just enough" to implement an accelerated and robust message bus.
I do admit it sucks that purchases are bound to the system and not to an account, leaving you at Nintendo's whim in a catastrophe, but that having been said I've been one of the lucky ones to get Nintendo's assistance in having my purchases moved to a new system after mine was stolen. The rep was very helpful, and although it was far from trivial (they required a letter, including documentation of the theft, they needed the old and new serial numbers) and good circumstance (My Nintendo account was linked to my Wii, and it apparently it was important that I NOT run the Wii Store app, something i could have not of known in advance; it was fortunate I called Nintendo early in the system setup process) I am very grateful for Nintendo's help in this.
The nouveau driver supports everything from NV04 upwards - NV01 and NV03 (NV02 never made it to production) are very different. In particular, PFIFO (the engine on the card that submits command the GPU) on NV01 doesn't support DMA at all, and NV03 has broken DMA. For that (and other) reasons, if support were desired for these cards, it would be in a separate driver. However such a driver would essentially be of academic interest, since these cards only accelerate simple shapes (like triangles and curves).
That having been said, one of the nouveau developers has done some reverse engineering of the NV01, the finiding of whic hare in the envytools notes.
This is already true under BIOS, since at least the mid 90's. As far back as the 386SL, there been a System Management Mode, which does exactly that. It performs important tasks like checking the processor and shutting it off/slowing it down if its get too hot, and emulating legacy hardware. It interrupts at indeterminate times, for an undetermined amount of time, and it can't be disabled (usually, but you wouldn't want to even if you could). this why "hard" real-time is impossible on x86 platforms.
144 in decimal is 220 octal, however.
I've posted this before but it bears repeating here. I my case, my apartment was burgled, and my Wii was stolen. I bought a new one and called Nintendo. I did not have to re-mail both Wiis like in the story (which would have been impossible, of course). I explained the situation, and I was instructed to write a small letter with the police report and serial #'s of both Wiis. They transferred it. Now, I admit the certainly not very convenient, but its a far cry from shipping a pair of Wii's to Nintendo.
You should have called Nintendo to explain the situation.
In my case, my Wii was was over a year old, and it wasn't damage - my apartment was burgled and my Wii stolen. (Fortunately I carry renter's insurance). I got a new Wii, called Nintendo explained the issues. I had not yet signed into the Wii Shop channel on the new Wii (which is good, becasue its important to NOT do so) They me send a letter with thep police report and the serial # of the old and new Wii. And sure enough, they moved all my old content to the new Wii.
WEP is "Wired Equivalent Privacy". It wasn't supposed to be very strong - about a secure a regular wired network. However, it wasn't known back then just HOW weak it was. As a stopgap measure, WPA PSK (TKIP) was created. Since it uses the same algorithm as WEP, (RC4), existing equipment could be easily upgraded with just a firmware/software update. A long-term solution WPA2 PSK (AES) was created as well.
WPA-PSK (TKIP) is still far, far better than WEP by many order of magintude, but WPA2-PSK is better, and if all you wireless devices support it (in particular the Nintendo DS DOES NOT, The DSi does, but not for DS games), then that preferred.
Fourth Law of Thermdynamics: There's always more entropy then you think there is, even when you take into account the Fourth Law of Thermodynamics.
I still wouldn't worry about the heat death of the universe, though, unlike those in the aforementioned link.
The more useful 5 second rule.
Don't confuse ffmpeg with libavcodec. Although libavcodec is part of of the ffmpeg distribution, and is used by many other program (mplayer especially), ffmpeg is more than that.
All this plugin does is speed up loading of Java applets. Its benign, and Sun provides instructions on how to turn it off: http://www.java.com/en/download/help/quickstarter.xml .
NFS(v4) would be a lot more accessible if Linux supported more methods than AUTH_SYS and Kerberos. 2 more mechanisms - SPKM3 (TLS-like) and LIPKEY (simple username/password, requires SPKM3)are mandated by the NFSv4 RPC. (SPNEGO and NTLMSSP mechanisms would be nice too). The kernel might have support for them, but userspace GSSAPI support for anything other the Kerberos is poor to nonexistent.
This used to be true, but not anymore. Now there's Server Name Indication - RFC3546, that would allow this. However, OpenSSL (and by extension, mod_ssl) does not support it. GNUTLS does, however (and there's a corresponding mod_gnutls for Apache.
But the damages aren't "punitive", they are "statutory". They aren't intended to punish the infringer, rather the are intended to grant the appropriate relief to the plaintiffs when "actual" damages can't be easily calculated (since no one knows how many works were infringed).
So if the Data Loss Database is a database of all the databases that have had data lost/exposed, if the Data Loss Database itself loses data, dose it list itself?
Now my head hurts
Yeah it needs a name that detracts from murder. How about the "Open Journled File System?
You will be at then some if it were avaiable. Keep in mind gasoline prices include heavy taxes (state, federal, excise, etc).
WINE is an unstable target (in terms of development, not performance), however. Furthermore lots of these MMORPGS have intrusive "anti-cheating" tools (And even among games, they have those obnoxious copy-protection schemes).
IT be nice if they were native, but the chances of game companies writing/porting against a more agnostic target (like SDL) are practically zero.
So at least in the near future, Linux users will happy with whatever little support crumbs we can get. But one day these digital dark ages of DMCA, DRM and Microsoft's monopoly will finally come to an end....
It may, in some sense, be literally true, but Cocmast's statement amount to little more than Equivocation.Keep in mind we impeached a President over the same kind of equivocation, for an issue far less material then Comcast's one.
Which is part of the reason why everyone's so mad - Comcast has been caught with the cigar in the dame, its time for them to come clean (which they should have done even before they were caught).
There's plans on doing that, the reason they didn't do it on pipes and socks is neither socket() nor pipe() has a "flags" argument. So far, there no consensus how to do this - new system calls could be created, but no one wants to wind up with something like Windows API where one has multiple versions of the same call (The ...Ex calls) and taking 20 different arguments, half of which are unused. A prctl could be used, but that's racy with multiple threads.
So this is a big problem.
The Linux developers generally looked down pathname-based security (for what I think are good reasons). That's one of the reasons like SELinux is venerated and AppArmor is snubbed. So this is no surprise. Especially given the VFS and namespace games you can play in Linux (bind mounts, slave mounts, /proc ).
So this is no surpise. chroot() is certainly useful, but not for keep root in jail; use SELinux for that.
Not necessarily; NTFS is both in the kernel AND in FUSE. However, the kernel version is less full-featured than the user-space version (ntfs-3G); because of lack of manpower and that author strict quality control - the old NTFS driver ate filesystems.
That said, I can't see ZFS ever being in the kernel - even licensing problems aside; its a HUGE layering violation. Some say they can do a ZFS without the layering problem; an ambitious project - btrfs exists to try do exactly that. Of course its nowhere near done (currently it'll oops if the filesystem gets full, among other things) - but its one to keep an eye on.