"When it breaks, you're fucked", just like anything you run as pid 1. Except you can still use the init= command line parameters to run something different (or possibly break= to stop in the initramfs).
"Obsoletes 20-30 years... of how to use linux tools". Huh, I must have my Linux history wrong as I could have sworn it was started in 1991.
"No real new features" because all its new features, are somehow not real according to some AC?
"Virtually untested" except by every major distribution?
Thunderbird tends to reformat mails after signing by Enigmail, invalidating the signature. Enigmail has some workarounds for this, but nothing perfect. The two projects should have worked together to hook Enigmail in at the right step, but somehow it's never happened.
Debian accidentally dropped support for 486 by turning on kernel stack smashing protection, which uses RDTSC. This was done before Debian 6.0 (squeeze) but we only recently received a report that it failed to boot on a 486.
No they wouldn't - the vast majority of silicon vendors are fabless, while some silicon developers don't even sell complete chips at all, only 'IP blocks'. It is absolutely possible to have free/open source chip designs.
I think the big stumbling block currently would be the very limited FOSS tools for synthesis and layout.
SMS allows 7-bit, 8-bit and variable-length (UTF-16) encodings, for 160/140/80 code units per message. The 140 character limit leaves some room to add a username prefix when users receive tweets by SMS in a 7-bit encoding.
Whatever the restrictions of SMS or the original Twitter service, tweets may now use any Unicode character (for some version of Unicode). Whenever they forward tweets by SMS, if they have to use an 8-bit encoding or UTF-16 they may need to split.
the trouble with DVCSs is there is no repository to backup.
There are many repositories you can backup. It's a matter of policy for each project to choose which of these is the authoritative version.
Everyone has their copies and a vape in one can (and will) be propagated to the others.
It sounds like you are talking about non-fast-forward pushes. These can be disallowed, and I think that's the default but I could be wrong. It's also not necessary to allow all developers to push to the authoritative repository (which you can't do with a centralised VCS).
Its not like a centralized system where you can have proper backups.
1. Kernel driver for hardware init, power management, mode setting, GPU buffer management and command submission
2. Userland library for GPU buffer management and command submission
3. OpenGL implementation
In the open source graphics stack, the kernel driver exposes KMS and DRM interfaces and potentially others. Parts 2 and 3 are part of libdrm and Mesa respectively. The display server can (I think) be built on top of KMS, libdrm and OpenGL and be independent of the hardware. However it will need an extension to OpenGL called EGL which will be specific to each display server protocol.
Currently X doesn't usually work that way for historical reasons - it used 2D acceleration first and still supports hardware that has only 2D acceleration. So it has hardware-specific drivers for each family of GPUs. However there is the 'Glamor' library that supports 2D acceleration genericallly on top of OpenGL, and I would expect to see a gradual move to that, not least because it's the only option for 2D acceleration in XWayland.
Getting back to Nvidia, their problem currently is that they don't implement the same interfaces as the open source stack and therefore don't work with the new display servers that depend on those interfaces. Implementing KMS gets them a long way there. However it sounds like they still need to reimplement the EGL, not because it's hardware-specific but because their OpenGL implementation is entirely independent of Mesa.
1. The allegations against Quinn are insinuations with no evidence behind them.
2. Sarkeesian has been loudly contradicted and claimed to be a con-woman by people that can't take criticism and are annoyed by the success of her Kickstarter.
3. This is being called "misogyny" in gaming because it is directed specifically at women.
4. The Social Justice Warriors have all supported these women because they oppose misogyny.
5. It's so cheap and easy to brand gamers basement dwelling vrigin men-children than it is to look at the facts. This is stereotyping, but it is nothing like the harrassment, online bullying, doxxing or death threats made by some gamers against feminist critics.
ASICs generally aren't flexible enough that you could simply emulate another controller in firmware, while FPGAs suck too much power to use on commodity network adapters. Writing a new driver (or bringing an existing neglected driver up to scratch) is going to be quicker than trying to make hardware that's compatible enough to work with a driver written for another vendor's controller.
(Besides which, as that other driver is probably maintained by your competitor, do you really think they're going to make an effort to ensure that their later updates are compatible with your clone controller? You'll still have to maintain your own fork.)
I have often wondered why there isn't a vendor-neutral register-level standard for Ethernet controllers, along the lines of AHCI and xHCI. There is the virtio networking standard, but as it's designed for VMs I assume it does not cover Ethernet link management. I seem to remember that VMware tried to promote a common interface for SR-IOV virtual functions at one time, but that didn't get very far. Again that would not have included link management.
Right. They want FreeBSD drivers, they can put that on the requirements list for network and storage controller vendors. But that does leave the issue of where the vendors are going to find good FreeBSD hackers to write these drivers.
Another example I noticed recently: LeCroy PETracer.
Qt by default uses native widgets wherever possible
I believe it imitates the look of native widgets but doesn't actually use them. This should allow for consistent behaviour on all platforms (unlike, say, WxWidgets).
It's a stock Debian kernel with some minor packaging changes and support for a new game controller. All those realtime patches? Not actually used by default.
The full list of exciting changes:
Make the binnmu regexp also reconize our build suffixes
New XBox controller driver
Disable Intel P-State driver as it causes issues with sound being choppy during BigPicture trailer video playback.
Hard-code parallel build for now since our OBS infrastructure doesn't know how to set these options yet.
Add postinst step to touch/var/run/reboot-required
Repeated merges have worked well for a while now (maybe since 1.6?). It's not quite as good at merging as git is, but it works well enough. But I have to agree with the general sentiment against merging from release to devel branches. Merging should be considered an expert-only operation (not expert in version control, but in the code base). Cherry-picking/backporting fixes from devel to release is safer because then you know exactly what you're changing.
Whenever a web site has a form, some other site can set up another (hidden) form pointing to the same URL and with any values they like. Someone who visits both sites can unintentionally submit that form (together with their cookies from the first site, so it's properly authenticated). This is 'Cross Site Request Forgery' and the usual way to avoid is to check the Referer header.
I personally haven't experienced abuse of my card details - so far as I know. But if I did, how could I tell who was responsible - especially when there are vast leaks like this? It seems like it would be more fair to have an industry-wide fund to compensate victims, which the leaking companies would pay into proportionately to the number of valid details leaked.
There's not 64k of assembly pumping bytes into a framebuffer and twiddling the PC speaker port to synthesize digital audio.
Of course. But all the creative work is squeezed into 64K.
One thing I couldn't find in there (and I've been out of the scene for a LONG time, so I don't know how this works on new-fangled fancy computers...) -- do these write directly to the video hardware? Or do they use OS services like DirectX11, etc?
They use DirectX, because that is the only way to support a reasonable range of hardware. (Also, you can't hit the hardware without installing a new driver or exploiting a kernel bug. Neither of which is very friendly.)
But are people still getting down and counting clock cycles?
Cycle counts aren't even documented today. Now it's all about avoiding cache misses and cache invalidation.
Slashdot Mirror
Path Intelligence (reference)
"When it breaks, you're fucked", just like anything you run as pid 1. Except you can still use the init= command line parameters to run something different (or possibly break= to stop in the initramfs).
"Obsoletes 20-30 years ... of how to use linux tools". Huh, I must have my Linux history wrong as I could have sworn it was started in 1991.
"No real new features" because all its new features, are somehow not real according to some AC?
"Virtually untested" except by every major distribution?
Insightful, my arse.
Because obviously broken jack detection is the fault of the daemon, not the hardware or sound driver.
In many hard drives the flash only has the first stage of the firmware, while the rest is on the disk - and there's lots of spare space there.
Thunderbird tends to reformat mails after signing by Enigmail, invalidating the signature. Enigmail has some workarounds for this, but nothing perfect. The two projects should have worked together to hook Enigmail in at the right step, but somehow it's never happened.
Debian accidentally dropped support for 486 by turning on kernel stack smashing protection, which uses RDTSC. This was done before Debian 6.0 (squeeze) but we only recently received a report that it failed to boot on a 486.
A mask set is not likely to be the "preferred form for modification"; for digital logic that would typically be VHDL or Verilog files.
No they wouldn't - the vast majority of silicon vendors are fabless, while some silicon developers don't even sell complete chips at all, only 'IP blocks'. It is absolutely possible to have free/open source chip designs.
I think the big stumbling block currently would be the very limited FOSS tools for synthesis and layout.
SMS allows 7-bit, 8-bit and variable-length (UTF-16) encodings, for 160/140/80 code units per message. The 140 character limit leaves some room to add a username prefix when users receive tweets by SMS in a 7-bit encoding.
Whatever the restrictions of SMS or the original Twitter service, tweets may now use any Unicode character (for some version of Unicode). Whenever they forward tweets by SMS, if they have to use an 8-bit encoding or UTF-16 they may need to split.
... quit reading Slashdot comments, ...
There are many repositories you can backup. It's a matter of policy for each project to choose which of these is the authoritative version.
It sounds like you are talking about non-fast-forward pushes. These can be disallowed, and I think that's the default but I could be wrong. It's also not necessary to allow all developers to push to the authoritative repository (which you can't do with a centralised VCS).
No, it's much better.
Also, wifi is half-duplex (no separate uplink and downlink frequencies) so any traffic in the other direction (like ACKs) reduces available bandwidth.
You need at least:
1. Kernel driver for hardware init, power management, mode setting, GPU buffer management and command submission
2. Userland library for GPU buffer management and command submission
3. OpenGL implementation
In the open source graphics stack, the kernel driver exposes KMS and DRM interfaces and potentially others. Parts 2 and 3 are part of libdrm and Mesa respectively. The display server can (I think) be built on top of KMS, libdrm and OpenGL and be independent of the hardware. However it will need an extension to OpenGL called EGL which will be specific to each display server protocol.
Currently X doesn't usually work that way for historical reasons - it used 2D acceleration first and still supports hardware that has only 2D acceleration. So it has hardware-specific drivers for each family of GPUs. However there is the 'Glamor' library that supports 2D acceleration genericallly on top of OpenGL, and I would expect to see a gradual move to that, not least because it's the only option for 2D acceleration in XWayland.
Getting back to Nvidia, their problem currently is that they don't implement the same interfaces as the open source stack and therefore don't work with the new display servers that depend on those interfaces. Implementing KMS gets them a long way there. However it sounds like they still need to reimplement the EGL, not because it's hardware-specific but because their OpenGL implementation is entirely independent of Mesa.
Despite that, Coca-Cola has now launched a variant with stevia and Pepsi apparently has a variant with stevia (only in some markets).
1. The allegations against Quinn are insinuations with no evidence behind them.
2. Sarkeesian has been loudly contradicted and claimed to be a con-woman by people that can't take criticism and are annoyed by the success of her Kickstarter.
3. This is being called "misogyny" in gaming because it is directed specifically at women.
4. The Social Justice Warriors have all supported these women because they oppose misogyny.
5. It's so cheap and easy to brand gamers basement dwelling vrigin men-children than it is to look at the facts. This is stereotyping, but it is nothing like the harrassment, online bullying, doxxing or death threats made by some gamers against feminist critics.
Fixed that for you.
ASICs generally aren't flexible enough that you could simply emulate another controller in firmware, while FPGAs suck too much power to use on commodity network adapters. Writing a new driver (or bringing an existing neglected driver up to scratch) is going to be quicker than trying to make hardware that's compatible enough to work with a driver written for another vendor's controller.
(Besides which, as that other driver is probably maintained by your competitor, do you really think they're going to make an effort to ensure that their later updates are compatible with your clone controller? You'll still have to maintain your own fork.)
I have often wondered why there isn't a vendor-neutral register-level standard for Ethernet controllers, along the lines of AHCI and xHCI. There is the virtio networking standard, but as it's designed for VMs I assume it does not cover Ethernet link management. I seem to remember that VMware tried to promote a common interface for SR-IOV virtual functions at one time, but that didn't get very far. Again that would not have included link management.
Right. They want FreeBSD drivers, they can put that on the requirements list for network and storage controller vendors. But that does leave the issue of where the vendors are going to find good FreeBSD hackers to write these drivers.
I believe it imitates the look of native widgets but doesn't actually use them. This should allow for consistent behaviour on all platforms (unlike, say, WxWidgets).
Repeated merges have worked well for a while now (maybe since 1.6?). It's not quite as good at merging as git is, but it works well enough. But I have to agree with the general sentiment against merging from release to devel branches. Merging should be considered an expert-only operation (not expert in version control, but in the code base). Cherry-picking/backporting fixes from devel to release is safer because then you know exactly what you're changing.
Whenever a web site has a form, some other site can set up another (hidden) form pointing to the same URL and with any values they like. Someone who visits both sites can unintentionally submit that form (together with their cookies from the first site, so it's properly authenticated). This is 'Cross Site Request Forgery' and the usual way to avoid is to check the Referer header.
The current Debian stable release (6.0, squeeze) has kFreeBSD ports for i386 and amd64.
Sam Hartman and Mario Lang gave a talk and demonstration of accessibility in Debian in 2009, covering various software in Debian (and Windows). Video is linked from the talk page.
I personally haven't experienced abuse of my card details - so far as I know. But if I did, how could I tell who was responsible - especially when there are vast leaks like this? It seems like it would be more fair to have an industry-wide fund to compensate victims, which the leaking companies would pay into proportionately to the number of valid details leaked.
There's not 64k of assembly pumping bytes into a framebuffer and twiddling the PC speaker port to synthesize digital audio.
Of course. But all the creative work is squeezed into 64K.
One thing I couldn't find in there (and I've been out of the scene for a LONG time, so I don't know how this works on new-fangled fancy computers...) -- do these write directly to the video hardware? Or do they use OS services like DirectX11, etc?
They use DirectX, because that is the only way to support a reasonable range of hardware. (Also, you can't hit the hardware without installing a new driver or exploiting a kernel bug. Neither of which is very friendly.)
But are people still getting down and counting clock cycles?
Cycle counts aren't even documented today. Now it's all about avoiding cache misses and cache invalidation.