Hear, hear. That's exactly the problem. The invariant of rename is useful, and it is useful to be able to get the atomic cutover without ensuring that the file is on disk. The previous ext4 behaviour is utterly useless to everyone. The reason is that there is an important case that hasn't been raised much: where the process doing the renaming isn't the process doing the writing. Consider:
$ echo "Hello, world" > file.new # or some other operation that produces file.new
$ mv file.new file
$ [System crashes some time after mv completes.]
In this case, the shell probably doesn't do an fsync before it closes file.new, so the bug might appear. Basically, the implication of not solving this is the kernel is that every application that writes a file needs to be changed to fsync before closing it, if someone else might later want to rename it over another file. That is equivalent to an enforced fsync_on_close flag, but also requires that every application is changed, and it completely wipes out the lazy allocation, write-behind optimisation that this was all supposed to allow. The only realistic possibility is for mv to open file.new and fsync it before renaming, but that's racy, so the kernel is the only place where this problem can be fixed properly.
I wouldn't recommend using only accelerometers to control a robotic arm. You'll get a buildup of integration error, which will cause the arm to keep going in a random direction with a constant velocity after you stop the accelerometers. Not a Good Thing with an expensive arm.:) (Of course, it's possible to damp out the velocity, but your position accuracy is still lousy.)
By "exceptions" he means exceptional (i.e. special) cases. There's tons of that stuff in AI and gameplay code. Games generally don't use neural nets or GAs or fuzzy logic or anything... it's all expert systems, min-max, pathfinding with heuristics, etc. The most important thing for game AI is not that it actually learns well (or at all), it's that it doesn't do blatantly stupid things. Game AI code tries to detect all the special cases so this doesn't happen. You can't guarantee that stupidity won't happen with learning algorithms.
On the question of whether a BEC made of quasiparticles is really a BEC: a laser beam fits (some) definitions of a BEC of photons, but most physicists don't immediately think laser beams when someone talks about BECs. I'd think that these "BECs" would be considered in the same way: technially a BEC perhaps, but not the definitive example of one. After all, the quasiparticles are just quantized vibrational modes of non-EM fields.
Yes, this is exactly right. TFA confuses WGA, which usually only runs when you try to use Windows Update or download certain MS downloads, with the WGA notification tool, which potentially nags you every time you log in. The distinction is IMHO deliberately vague, but zdnet doesn't exactly look technically competent by not understanding the difference when there's stuff all over the Windows Update message boards about it. The story could be just as well be titled, "ZDNet misunderstanding WGA's functionality?"
I did the same, and my system doesn't have "wgalogon.dll" in the system32 dir, as other machines with the WGA notification tool apparently do. So disabling the update seems to work.
To re-register a DLL, re-run the command, but omit the/u switch.
Unregistered or incorrectly registered DLLs are the cause of a quite a lot of Windows problems (so if you have random problems with image viewing in the shell after running that command, you know why).
An example in C of where you might want to use an assignment in an if statement:
void *pdata;
if (pdata = malloc(numbytes)) { /*Do something here if the memory allocation succeeded*/ }
Sure it might not be your style, but the meaning is quite clear to an experienced C programmer. It's similarly useful with other functions that return zero or a null pointer on failure, but useful data on success. Other things in C like the conditional operator and the comma operator fall into the same category: kind of neat, but really only used in relatively limited situations.
Yeah, it really isn't true. Windows XP's preloading feature is something that Linux doesn't have at the moment, and it makes a significant difference both for system startup and app startup.
The XD/NX bit is applied on a page-by-page basis. Marking pages as executable or not wasn't previously possible on x86 architecture. Marking pages as read-only or read-write, user or supervisor, or present or absent was possible. i386 and above have always been able to mark segments as code or data (data segments aren't executable, and code segments aren't writeable), but a flat addressing scheme combined with paging was so much easier on both application developers and OS writers that noone ever really used the segmented addressing features. So what happens is that a "modern" x86 O/S aliases a flat 2/4GB code segment over the top of a 2/4GB data segment, and uses the memory paging features to do all their memory mapping. This basically removes the no-execute protection that you get when using the segmented addressing features. Hence the need for an NX bit on a page level, which is what NX is.
x86 processors have always been confusing with both segmented and paged memory management:).
The FTA does not change any aspects of the Australian patent laws. Full stop. Software is already patentable under Australian law. Australia has had to respect US patents anyway for some time due to WIPO treaties. However, Australian patent law doesn't (seem to, anyway) allow for the same harassment that large companies can get away with in the US.
Copyright is another kettle of fish. Australia conceded a lot of ground to US interests there. Read my last post from my posting history.
There's almost no facts in the comments here, mostly just anti-Howard or anti-American ranting. The senate published a report that summarizes submissions on the FTA, and the committee's evaluation of the agreement. Chapter 3 summarizes the intellectual property aspects.
Summary of the summary:
The main concession on an IP front is Australia extending its copyright term from life+50 years to life+70 years. This was seen by the negotiating parties as Australia's main concession in the agreement, in return for US concessions in other (non-IP) areas. The US pushed very hard for this, and was prepared to concede quite a bit of ground in other areas. They wanted life+95 yrs but didn't get it. Australia gained quite a bit by holding out until making a rather late comprimise. This is apparently "more in line" with WIPO treaties that most other developed countries have already signed up for, but not the life+95 years that the US has.
Most submissions were against the copyright extension. Reasons for this include that Australia is a net importer of IP, the US is a net exporter, and that this is a clear benefit to the US rather than Australia. A recent report (2000 or so) recommended not increasing the term of copyright, but an even more recent report comissioned since FTA negotiations started recommends it (the Committee notes that this report is dodgy).
DFAT representatives commented that Australia does not have hard and fast obligations to adopt all the US-style copyright laws:
If you look at that language, it
talks about 'endeavouring to work together'. It is a best-endeavours clause;
it does not commit Australia. There are no obligations there for Australia to
harmonise anything but rather to work with the United States and where
appropriate--if future governments decide it appropriate--to work together
in those areas. It is a best-endeavours clause and there are no obligations
there.
And:
It is fair to say that the response has been unsurprising in the sense that you
can see continuing divergent views on some aspects of intellectual property.
We have been at pains to explain to those music interests that are concerned
that, whilst we have strengthened copyright in some areas, we have retained
the ability to make exceptions and that, whilst we have agreed to adopt
elements of United States law, we have not agreed to implement US law
word for word. Therefore, continued consultations with industry about the
most appropriate way to do that in the context of our regulatory and legal
environment are important.
There were a number of submissions advocating lower copyright terms for the benefit of consumers of copyrighted material. (These are more or less standard fare on Slashdot, but better worded;) )
Submitters argued for Australia to adopt the US's more liberal fair-use (called "fair dealing" in Aus, but quite different in what's allowed) provisions (on a related note, most owners of iPods in Australia are breaking the law, but the govt wants to get rid of such stupidities). Australia also does not have the originality requirement that the US has for copyright to apply. The govt is apparently still considering doing this, but it's not in Howard's legislation.
The committee is concerned about the potential abuse of the extended copyright term. It thinks that US antitrust law or European law is more likely to stop abuses than Australian consumer protection law. The committee doesn't think that DFAT (dept of foreign affairs) demonstrated sufficient technical competance when answering questions on copyright law.
The FTA provides for copyright holders to enforce more restrictions than provided for by fair-dealing by making a contract with copyrigh
Atmospheric pressure is about 10^5 pascals = 100 Kilopascals. 100 isn't too hard to deal with. You generally don't measure the distance across the continent in inches or feet, and you generally don't talk about pressures around atmospheric pressure in pascals. Weather people use the prefix "hecto" to mean 1e2 (though "hecto" isn't very common outside meteorology), so standard atmospheric pressure is 1013 hectopascals. This means that you can look at normal variations of atmospheric pressure without worrying about numbers with decimal points.
And 10^5 is an easier number to multiply or divide by than 14.7 (or 15) anyway.
If you want to be pedantic, there are four different classical one-bit input and output gates (because each of the two possible inputs has two different output possibilities, and 2^2=4). They are the Not gate, the Buffer gate, a gate that always outputs one regardless of its input, and a gate that always outputs zero. The latter two aren't terribly useful as gates -- you don't need the input at all. So you're pretty much right: there are only two useful classical single-bit input and output gates.
I haven't tried this (I don't have any DRM'd WMAs to test), but my copy of Winamp has this in the Changelog:
Winamp 2.61:
* In accordance with Microsoft's license agreement, we no longer allow you to
use DSP plug-ins or alternate output plug-ins when playing WMA files.
Do you have version of Winamp older than 2.61? Or a new version (version 5 or whatever)? Or is the changelog lying to me?
I've got another question, and this seems to be a good place to post it:
I understand that gates were originally metal in the early days of FETs, but then were changed to polysilicon. IIRC, one of the reasons was that metal gates are much more susceptible to electrostatic discharge (this only affects interface transistors, though, not the internal ones). And I seem to recall that polysilicon can generally be lithographically etched thinner than metal can, so you can get shorter transistors and smaller gate capacitance. Is the idea of a metal gate that revolutionary? The article at news.com.com suggests that the metal gate stops phonon scattering.
Am I correct about the early use of metal gates? And how does the metal gate absorb phonons or prevent scattering? news.com.com says something about reducing electron mobility (I assume this wouldn't affect electron mobility in the channel... not something you really want to decrease).
Some Belgian Linux programmers ("hackers" because they have worked out how to get hardware to do things other than what it was intended to) met this week-end to get Linux running on DLink 614ap+ wireless networking access points (the little receivers that act like hubs or swtiches for wireless networks). (DLink is the brand, and 614ap+ is the model.) These access points have CPUs in them to handle configuration tasks and whatnot. The CPU in these particular access points was the Samsung 4510 chip. They have compiled and run a specialized, stripped down version of Linux called "uClinux" (the uC is an abbreviation of "microcontroller"; the micro symbol looks like a "u") on the microcontroller in the access point.
The access points also contain a Texas Instruments ACX100 wireless chipset, which does the signal processing necessary for the 802.11b protocol that the device supports. The ACX100 also allows devices to communicate at 22mbps with other wireless network cards or access points that use the ACX100, using a proprietary method. This chipset has caused headaches for Linux users (PC Linux users) who own wireless networking cards that use this chipset, because Texas Instruments haven't released documentation on how the chipset works. This makes writing a device driver difficult, and so Linux users can't use wireless networking if they own a wireless network card based on these chipsets.
There's still some work to do. (I think they mean that they haven't worked out how to use the ACX100 from the microcontroller.) If you want to help, and you've got one of these access points (i.e. it says it supports 22mbps and 802.11b), open up your access point. Once it is open, build a JTAG adaptor (JTAG is a protocol that is used to communicate with embedded microcontrollers and programmable hardware). Get your JTAG adaptor to plug into your PC (probably via a serial or parallel port) and read or re-write the flash memory (i.e. the memory where the program code that runs on the microcontroller is stored). If you can read the memory, sending the memory contents to these people might help them understand how the ACX100 works in more detail. I doubt you'd want to re-write the memory unless you're testing code with them and you're willing to end up with a useless brick instead of a wireless access point. From their screenshots, they have written a bootloader that they write to the access point's flash memory. The bootloader downloads uCLinux from one of the computers plugged into it (i.e. normal wired ethernet), and runs it.
And hey, here's a thought: how about purchasing voting machines from non-profits?
I think that one has to be even more wary of this than purchasing voting machines from companies. Although it seems trendy to generally bash companies as amoral and working against the interests of society, I'd like to point out that a non-profit organization (especially one that makes voting machines) would probably not be policitally impartial, either. At least when buying machines from a company, the company has some known motivation for producing a fair machine: money. A non-profit has no such obvious motivation---the government and the voters must trust the intents of the non-profit organization, and their members, entirely. If the organization has political beliefs (which many do, even if not in their constitution), then members of the organization would be more likely to exact a "payment" for their services than paid employees. There's no such thing as a free lunch; in fact, the cheapest lunch is often the one that you pay for with your own money.
You can turn off DCOM RPC (where the vulnerability is). Some services won't work, but if you're not running a server, then you won't notice. If you are running a server, you've got to reboot to patch anyway, so there's no big deal. System calls are NOT implemented with DCOM RPC. Some Shell, DirectX, and Windows Media calls (for example) are implemented using COM, but there is no remote vulnerability there, and disabling the DCOM service doesn't affect this.
If you want to know how, run "dcomcnfg" as an administrator, go to "Default Properties" (you have to choose "This computer" on WinXP first) and uncheck "enable DCOM on this computer". Press OK.
IMHO, it's irrelevant whether they are real objects or not. The reason why people see a paradox is because they are not accustomed to seeing an infinite sequence (i.e. each of the time steps) summing to a finite real number (the total time taken for the hare to overtake the tortoise).
So it's just that most people don't understand math, and analysis (limits, sequences, series, calculus etc.) in particular. Physicists use this sort of mathematical construction all the time to model reality, and the fact that reality isn't quite like that at a microscopic level doesn't resolve the paradox in and of itself.
Windows does have a device independent graphics interface. It's called GDI, and Windows has had it since Windows 1.0. This is one reason that Windows printing is generally more WYSIWYG than on other some other platforms which have different display/printer interfaces. It's just that many programs are written badly: they use the absolute pixel scaling mode, and don't respect the user's display settings.
GDI can easily be set to use millimetres as the dimension, or inches, or whatever. But it doesn't always give great results when you're drawing things like icons, which have standard pixel sizes to make them look good on a screen. And most display drivers report a 96 DPI screen by default, no matter what the screen actually is, because of badly written programs that expect 96 DPI screens. So most programs don't use the device-independent scaling modes when drawing their user interfaces. Those that play nice with large fonts generally use special code to scale UI components properly when the user has a different font size selected. Some widget APIs do this automatically: QT, GTK, and Borland's VCL come to mind.
So it's the misuse of the existing standards which has caused this problem, rather than the lack of any device-independent interface.
Mobile protocols, including GSM, are almost always asymmetric, in that the base station and mobiles aren't created equal. It reduces complexities in the protocol to not allow direct mobile-mobile links. In particular, it reduces the implementation complexity on the mobile side. For an example, consider what would happen if one user moves out of range of a cell and gets handed over to an adjacent cell. How does this affect a direct mobile-mobile call negotiated with the original cell?
Mobile transceivers are not as powerful as the base station's tranceivers, and are generally closer to the ground. Hence, two phones both on the same base station often wouldn't be able to communicate with each other anyway because of insufficient power.
Many operators bill mobile calls by the minute. This is harder if mobile users can directly talk to each other. If users are on a "pre-paid" billing arrangement, then the operator can't disconnect the call if one party runs out of credit.
The inefficiency incurred by relaying such call through the base station is small, anyway.
Slashdot Mirror
Hear, hear. That's exactly the problem. The invariant of rename is useful, and it is useful to be able to get the atomic cutover without ensuring that the file is on disk. The previous ext4 behaviour is utterly useless to everyone. The reason is that there is an important case that hasn't been raised much: where the process doing the renaming isn't the process doing the writing. Consider:
$ echo "Hello, world" > file.new # or some other operation that produces file.new
$ mv file.new file
$ [System crashes some time after mv completes.]
In this case, the shell probably doesn't do an fsync before it closes file.new, so the bug might appear. Basically, the implication of not solving this is the kernel is that every application that writes a file needs to be changed to fsync before closing it, if someone else might later want to rename it over another file. That is equivalent to an enforced fsync_on_close flag, but also requires that every application is changed, and it completely wipes out the lazy allocation, write-behind optimisation that this was all supposed to allow. The only realistic possibility is for mv to open file.new and fsync it before renaming, but that's racy, so the kernel is the only place where this problem can be fixed properly.
Were you looking for the IsNot patent? It was covered on /. a couple of years ago. The patent specifically refers to Visual Basic .NET.
I wouldn't recommend using only accelerometers to control a robotic arm. You'll get a buildup of integration error, which will cause the arm to keep going in a random direction with a constant velocity after you stop the accelerometers. Not a Good Thing with an expensive arm. :) (Of course, it's possible to damp out the velocity, but your position accuracy is still lousy.)
By "exceptions" he means exceptional (i.e. special) cases. There's tons of that stuff in AI and gameplay code. Games generally don't use neural nets or GAs or fuzzy logic or anything... it's all expert systems, min-max, pathfinding with heuristics, etc. The most important thing for game AI is not that it actually learns well (or at all), it's that it doesn't do blatantly stupid things. Game AI code tries to detect all the special cases so this doesn't happen. You can't guarantee that stupidity won't happen with learning algorithms.
On the question of whether a BEC made of quasiparticles is really a BEC: a laser beam fits (some) definitions of a BEC of photons, but most physicists don't immediately think laser beams when someone talks about BECs. I'd think that these "BECs" would be considered in the same way: technially a BEC perhaps, but not the definitive example of one. After all, the quasiparticles are just quantized vibrational modes of non-EM fields.
Yes, this is exactly right. TFA confuses WGA, which usually only runs when you try to use Windows Update or download certain MS downloads, with the WGA notification tool, which potentially nags you every time you log in. The distinction is IMHO deliberately vague, but zdnet doesn't exactly look technically competent by not understanding the difference when there's stuff all over the Windows Update message boards about it. The story could be just as well be titled, "ZDNet misunderstanding WGA's functionality?"
I did the same, and my system doesn't have "wgalogon.dll" in the system32 dir, as other machines with the WGA notification tool apparently do. So disabling the update seems to work.
Unregistered or incorrectly registered DLLs are the cause of a quite a lot of Windows problems (so if you have random problems with image viewing in the shell after running that command, you know why).
Yeah, it really isn't true. Windows XP's preloading feature is something that Linux doesn't have at the moment, and it makes a significant difference both for system startup and app startup.
x86 processors have always been confusing with both segmented and paged memory management :).
Copyright is another kettle of fish. Australia conceded a lot of ground to US interests there. Read my last post from my posting history.
Summary of the summary:
And:
And 10^5 is an easier number to multiply or divide by than 14.7 (or 15) anyway.
If you want to be pedantic, there are four different classical one-bit input and output gates (because each of the two possible inputs has two different output possibilities, and 2^2=4). They are the Not gate, the Buffer gate, a gate that always outputs one regardless of its input, and a gate that always outputs zero. The latter two aren't terribly useful as gates -- you don't need the input at all. So you're pretty much right: there are only two useful classical single-bit input and output gates.
Just an idle thought.
I understand that gates were originally metal in the early days of FETs, but then were changed to polysilicon. IIRC, one of the reasons was that metal gates are much more susceptible to electrostatic discharge (this only affects interface transistors, though, not the internal ones). And I seem to recall that polysilicon can generally be lithographically etched thinner than metal can, so you can get shorter transistors and smaller gate capacitance. Is the idea of a metal gate that revolutionary? The article at news.com.com suggests that the metal gate stops phonon scattering.
Am I correct about the early use of metal gates? And how does the metal gate absorb phonons or prevent scattering? news.com.com says something about reducing electron mobility (I assume this wouldn't affect electron mobility in the channel... not something you really want to decrease).
Some Belgian Linux programmers ("hackers" because they have worked out how to get hardware to do things other than what it was intended to) met this week-end to get Linux running on DLink 614ap+ wireless networking access points (the little receivers that act like hubs or swtiches for wireless networks). (DLink is the brand, and 614ap+ is the model.) These access points have CPUs in them to handle configuration tasks and whatnot. The CPU in these particular access points was the Samsung 4510 chip. They have compiled and run a specialized, stripped down version of Linux called "uClinux" (the uC is an abbreviation of "microcontroller"; the micro symbol looks like a "u") on the microcontroller in the access point.
The access points also contain a Texas Instruments ACX100 wireless chipset, which does the signal processing necessary for the 802.11b protocol that the device supports. The ACX100 also allows devices to communicate at 22mbps with other wireless network cards or access points that use the ACX100, using a proprietary method. This chipset has caused headaches for Linux users (PC Linux users) who own wireless networking cards that use this chipset, because Texas Instruments haven't released documentation on how the chipset works. This makes writing a device driver difficult, and so Linux users can't use wireless networking if they own a wireless network card based on these chipsets.
There's still some work to do. (I think they mean that they haven't worked out how to use the ACX100 from the microcontroller.) If you want to help, and you've got one of these access points (i.e. it says it supports 22mbps and 802.11b), open up your access point. Once it is open, build a JTAG adaptor (JTAG is a protocol that is used to communicate with embedded microcontrollers and programmable hardware). Get your JTAG adaptor to plug into your PC (probably via a serial or parallel port) and read or re-write the flash memory (i.e. the memory where the program code that runs on the microcontroller is stored). If you can read the memory, sending the memory contents to these people might help them understand how the ACX100 works in more detail. I doubt you'd want to re-write the memory unless you're testing code with them and you're willing to end up with a useless brick instead of a wireless access point. From their screenshots, they have written a bootloader that they write to the access point's flash memory. The bootloader downloads uCLinux from one of the computers plugged into it (i.e. normal wired ethernet), and runs it.
I think that one has to be even more wary of this than purchasing voting machines from companies. Although it seems trendy to generally bash companies as amoral and working against the interests of society, I'd like to point out that a non-profit organization (especially one that makes voting machines) would probably not be policitally impartial, either. At least when buying machines from a company, the company has some known motivation for producing a fair machine: money. A non-profit has no such obvious motivation---the government and the voters must trust the intents of the non-profit organization, and their members, entirely. If the organization has political beliefs (which many do, even if not in their constitution), then members of the organization would be more likely to exact a "payment" for their services than paid employees. There's no such thing as a free lunch; in fact, the cheapest lunch is often the one that you pay for with your own money.
If you want to know how, run "dcomcnfg" as an administrator, go to "Default Properties" (you have to choose "This computer" on WinXP first) and uncheck "enable DCOM on this computer". Press OK.
So it's just that most people don't understand math, and analysis (limits, sequences, series, calculus etc.) in particular. Physicists use this sort of mathematical construction all the time to model reality, and the fact that reality isn't quite like that at a microscopic level doesn't resolve the paradox in and of itself.
GDI can easily be set to use millimetres as the dimension, or inches, or whatever. But it doesn't always give great results when you're drawing things like icons, which have standard pixel sizes to make them look good on a screen. And most display drivers report a 96 DPI screen by default, no matter what the screen actually is, because of badly written programs that expect 96 DPI screens. So most programs don't use the device-independent scaling modes when drawing their user interfaces. Those that play nice with large fonts generally use special code to scale UI components properly when the user has a different font size selected. Some widget APIs do this automatically: QT, GTK, and Borland's VCL come to mind.
So it's the misuse of the existing standards which has caused this problem, rather than the lack of any device-independent interface.
This may not be the best story to post personal accounts like this ;).
- Mobile protocols, including GSM, are almost always asymmetric, in that the base station and mobiles aren't created equal. It reduces complexities in the protocol to not allow direct mobile-mobile links. In particular, it reduces the implementation complexity on the mobile side. For an example, consider what would happen if one user moves out of range of a cell and gets handed over to an adjacent cell. How does this affect a direct mobile-mobile call negotiated with the original cell?
- Mobile transceivers are not as powerful as the base station's tranceivers, and are generally closer to the ground. Hence, two phones both on the same base station often wouldn't be able to communicate with each other anyway because of insufficient power.
- Many operators bill mobile calls by the minute. This is harder if mobile users can directly talk to each other. If users are on a "pre-paid" billing arrangement, then the operator can't disconnect the call if one party runs out of credit.
The inefficiency incurred by relaying such call through the base station is small, anyway.