I have both Win 7 and Ubuntu running on this system (concurrently, the Ubuntu is a VirtualBox fullscreened on the second monitor), and I find your post interesting because on Windows side I have like 2 dozen icons pinned to the taskbar. Basically anything I need even semiregularly. On the Ubuntu, I have 2 icons in the Gnome panel: Firefox and gnome-terminal. I never use the Firefox icon. I think it was there by default. If I need Firefox on the Ubuntu for some reason (usually I browse with Chrome from the Windows) I'll do the same thing I do with any program other than terminal (which I usually have around 10 open on each of the 4 virtual desktops): open yet another terminal and type: firefox &
My thoughts exactly. At work (as a sysadmin) I'm running a Windows desktop with 2 screens. On the second screen (which isn't really essential, but still nice) I have a VirtualBox Ubuntu installation fullscreened 24/7. So I basically have two systems side-by-side except:
I have one mouse and one keyboard.
I can see what's going on in both OS at the same time
I only need to lock/unlock my console once
I can seamlessly copy-paste between them.
If I need to remote from home, I can just take normal RDP and the Ubuntu is available in a window too.
Even useless eye-candy in compiz works fine (though it's a bit slowish with RDP over interwebs). Both systems run all the time (well, the Windows needs to be booted occasionally where as KSplice deals with the Ubuntu pretty well), and they work just fine. From work-flow point of view it's mostly like working with a single system.
I also have a console switch so I can access a separate Mac (for OSX) from the same console. It works too, but it's such a pain to hop from one system to another that I usually try to avoid having to bother. What this "hot switching" sounds like is basically like using such a console switch. Doesn't sound so great when you're used to being able to just focus another window.
But it can be mitigated by using external USB drives and the 'dd' command, which allows an entire file system to be stored as an image file and then restored or even mounted temporarily.
No need to use 'dd' as you can just take a tar-ball of one filesystem. That way you don't waste space on storing (and more importantly moving) the garbage in unallocated space. There's nothing special about any of it, except whatever the bootloader (ie. grub hopefully) requires. You can use some Live ISO (usually the same one you used to copy the data over) to chroot into the system once the data is copied over and tell grub to reinstall itself (update-grub). The only other tweak required is patching new UUIDs to/etc/fstab (or you can give the old UUID to mkfs too I guess, though this could cause problems if you try to connect both drives at the same time).
I'd guess (and this is a pure guess) if you look at the life expectancy vs. attitude and quantize the attitude on a binary scale (positive thinking vs. depression) you'll see a corralation between life expectancy and positive thinking. But what happens if we compare positive attitude vs. realistic (or "average") attitude?
It could be that negative attitude correlates with shortened life-expectancy, but once your attitude improves back to what can be considered "normal" there is no further advantage in being more positive. Kinda like some sort of "dimishing returns" situation?
And since we can expect Microsoft to know how to do that, we could also expect that instead of NSA, it's Microsoft that holds the backdoor to the generator in Vista. No?
And now somebody probably should say: You must be new here.
Rationale: one is not supposed to RTFA on/.
That said, I personally kinda like legalese, patent-speak, and other dialects of formalese. They appear to be kinda like somewhere between natural and formal languages. The rules seem too strict for a truly natural language, yet not strict enough to be parsed with a formalized grammar. Most of the potential ambiguity is removed (or reduced), yet the expressive power doesn't seem to be artificially limited. If one could somehow take such a language just a couple of steps towards formalization to allow mechanical parsing and then replace the rather heavy-weight syntactical forms with something more digestible, maybe that would be an interesting basis for a semi-programming language for human-computer interaction. I mean, seriously.
Having written one or two drivers for a completely irrelevant toy operating system of mine (making me just marginally less incompetent to comment on this thread), it is very helpful to have datasheets that actually describes the operation of a given device, instead of just something like a list of it's registers and their meaning. Even descriptions of sequences of commands required are not always helpful without understanding the internal workings of the device. The resulting code ofcourse has to take all relevant device details into account, but the code itself is typically not sufficient to figure out anything beyond what the original code has at least attempted to take into consideration, if even that (ofcourse any sample code is invaluable when trying to decipher datasheets but that's another issue).
So based on what little I understand about the whole subject, I'd say letting somebody develop a driver under NDA and just releasing the driver source instead of all the documentation is likely to keep a LOT more details about the device essentially secret, even if the code itself was pretty decently commented with remarks about the particular implementation (assuming ofcourse that said internal documetation isn't duplicated in the comments).
Ofcourse that DOES have the effect that anybody willing to improve the driver functionaly in regards to the device would need the same documents under NDA (or reverse-engineer the relevant details, which might be easier with a working driver to tweak), but at least a source driver let's the kernel developers deal with things like driver API changes internally. Say, you want to change the protocol by which drivers reserve IO resources because you've found a new, totally fair way to do that. Now, with binary drivers you can either break the drivers or implement workaround wrappers. Source drivers, you can simply change the driver code yourself without having a clue what the driver actually does.:)
What's news is that we're still dragging our heels on IPv6. We dodged the bullet once by developing and widely deploying NAT and at the same time reclaiming large amounts of unused address space via switching core routing to CIDR. However, that trick only bought us a certain amount of time. As the world becomes increasingly connected, we're going to face the same problem again. Why are we waiting until it's a crisis to deal with it?
I believe the root problem here is that instead of fixing just the biggest problem (address space running out), IPv6 was destined to try to solve a number of other unrelated problems, which could just as well be fixed separately if desired. I mean sure, end-to-end encryption is important in many cases, but we're doing that on application level just fine. Sure, autoconfiguration is nice, but DHCP is practically everywhere.
I mean, if all IPv6 ever did was take the IPv4 spec, multiply the length of the addresses, and set a block of the IPv6 block as the "legacy block" containing the old IPv4 network, I bet most of us would have been running this extended protocol 5 years ago, and nobody would talk much about it anymore. Slowly all software would get modified, and we could have operating systems translate the lowest level IP packets from legacy address to new ones and back to help with the transition, and gradually get application support, essentially having a functioning new network behaving the same as the old one, but with tons of unused addresses to start using when everything is ready. But no. Instead it was destined to solve the world hunger. And I thought IP was supposed to route packets.
So therefore, I will now suggest the following protocol for RFC and RFI:
---
The IPv4x4 Internet Protocol:
This new protocol family shall function exactly the same as legacy IPv4 based protocol family with the following extensions:
1. Every 4 byte field containing an IP address shall be extendeed to 4x4=16 bytes, containing an IPv4x4 address.
2. Every IPv4x4 address within the subnet 128.69.69.69.69.69.69.69.69.69.69.69.0.0.0.0/96 shall be interpreted as a legacy IPv4 address.
3. Top half of the address range (addresses with the first octed having value higher than or equal to 128) shall be reserved for future rationalisation of special block allocations. Lower half is available for normal unicast addresses, except for all zeroes which will be reserved for global broadcast and must be routed to every location including legacy IPv4 networks except where an equivalent legacy IPv4 network would fail to route such a broadcast. No other rationalisation of private blocks or multicast blocks from legacy address ranges to new ranges is done at this point.
4. Any other issues with the legacy IPv4 protocols must be addressed on protocol layers other than the IPv4x4 Internet Protocol.
----
That said, I have a strange Deja Vu... I think it must have been at least 5 years ago...:P
It's actually a stupid issue with pretty much all parties faulty. After reading tons of posts which all confuse it all, I did RTFKBA and RTFRFC. From the RFC and the KB article, the following facts can be found:
1. There is one flag in DHCP protocol, the "BROADCAST" flag. The "Clarifications to BOOTP (RFC 1542)" gives a nice description of it's purpose (referenced from DHCP RFC2131).
2. Normally the server sends DHCP replies as unicast packets to a specific node.
3. It is suggested there are TCP/IP implementations unable to receive such a unicast packet before they have been fully configured, in which case they should set "the flag" to request that the server sends it's reply as a broadcast instead. Server should honor such a request. I guess such an implementation would configure their local MAC (or equivalent?) at the same time with their IP level settings, which might be a sensible thing to do in a simplistic single family (IP-only) network stack, which was designed before anybody thought of "auto-configuration" things like DHCP.
4. For some unknown reason, Vista sends DHCP requests with "the flag" set by default, even if it doesn't have said inability to receive unicast packets before being fully configured.
5. A DHCP server should honor such a request, though from reading the discussion here, I futher conclude that for various reasons, maintainers of certain servers and/or networks are unwilling to support broadcast replies to DHCP requests. At least in case of centralized DHCP servers this seems a reasonable decision.
Now, it's likely that MSFT has some purpose for setting the broadcast flag (other than pissing people up). So far this purpose is more or less a mystery to me. One possible reason I can immediately think of would be allowing a DHCP server to detect the presence of another DHCP server by monitoring DHCP reply broadcasts that somebody else sent (that could be useful for certain types of "zero-config" networking maybe?). But then again they might have another reason? Who knows.. maybe they wanna start selling DHCP relays? Or maybe they want Vista users to get static IPs?
Anyway, it doesn't seem like anyone is breaking the letter of the standard, as the DHCP requests Vista's sending are technically valid (although the flag isn't set for the specific rationale it exists for), yet the servers/networks/whatever aren't really required to support the flag either (although they "should").
My hobbies include some signal processing and music production stuff, and I definitely agree with you. But I want to add, that even with cheap headphones, it tends to be easier to hear non-linearities than with speakers, especially in not-so-optimal listening conditions, because there's no reverb, and you hear each channel separately. Other subtle effects are also easier to notice (which can be a problem when listening to a headphone mix from speakers).
I personally get very annoyed nowadays when listening to commercially produced new music from headphones specifically because they often have been driven so hard through a limiter, that the effect is well past compression and sounds more like plain old-fashioned clipping.. which can be nice on individual tracks, but rarely on master.
Some amount of compression is essential for certain types of pop-music, and compressors can be used to enchance dynamics as much as reduce them; the real problem is when perfectly well sounding mixdowns are destroyed by "mastering" them with stupid amounts of "compression" essentially turning the whole track/album/whatever into a glorified pulse-width-modulation.
Yeah well, one even nowadays sees schemes like flashplayers used to stream normal mp3s over normal http connection, used to prevent people from saving the mp3s involved. Same with videos too. I'd say against normal person it's probably pretty effective.:)
I'd guess the idea is that if you are going to give each of two CPU hogs exactly 50% of CPU, you don't need an explicit timeslice as such, only some threshold of how much difference is 'unfair' enough to pre-empt the process. Say, we set the threshold at 2% then we run process A until it's got 51% of CPU, at which point we run process B until it's got 51% of CPU and so on.
For the simple case of two processes then, it seems like we have timeslices, but once stuff starts changing dynamically any "timeslice" can basicly become arbitrarily short or long.. and ofcourse we don't need to consider the threshold value at all when we consider which process to schedule, because it would only be necessary to avoid constant pre-emption when two competing tasks are already in balance.
Could ofcourse be that I've completely failed to understand the CFS concept, but the above I'd guess based on what the author explained above.
In my opinion the "safe" ways to roll a platform-independent app out to everyone are to use a completely server-side web application platform or to program in APIs which are available to every client. [...]
In my opinion the "safe" way of rolling a platform-independent app is to write it in ANSI C, using only standard libraries (stdio should be enough for everyone), and not expecting any special kind of terminal emulation. Granted, you need to expect a C compiler, or provide pre(hand?)compiled binaries, but platforms without acceptable C compilers tend to be old enough that you're going to have trouble finding replacement capacitors for the blown ones, let alone finding suitable replacement tubes.
If internetworking is required, pretty much every operating system comes with some form of telnet. Just don't assume any particular terminal emulation, input buffering, character encoding... Just because it's called telnet also doesn't mean it actually understands telnet commands. Backspace processing is definitely not worth it, too many different conventions there, and people should learn to type right.
How about labelling mainland China as "P.Republic of China" and Taiwan as "P.Republic of China". Taiwanese probably don't have a problem with calling mainland "People's Republic of China", and we can claim them "P.Republic of China" stands for "Provice of Republic of China" (as in, the only one not conquered by this "P.Republic of China" standing for "People's Republic of China"). Then just tell the communists that it was printed twice to emphasize that the island of Taiwan is also part of "People's Republic of China".
If they are not convinced, explain that abbreviating saves datafile size, and hence results in faster transfers, more productive map browsing, translating directly to rising futures and/or more equal distribution of wealth.
As a long time Linux user and developer, I recently started learning a bit of Windows programming as well. It wasn't a good choice. It made me envy every single Windows developer.
Microsoft's best product ever is the Win32 API. It's somewhat sad to see that they seem to be trying to replace it with something worse. But as long as it lasts, it's pretty much the developers dream (the actual implementation might not be).
I'm probably not going to install Windows any time soon. I don't like it as a user, and I can cross-compile with Mingw on Linux just fine. Wine let's me do the initial tests, and I can use my girlfriends box to do the rest.
But I don't see myself doing that much (non-server) Linux development in the future, at least not until X is replaced with something else. Preferably with something that fits into the POSIX API. At present, mixing the two is just too painful.
PS. The network transparency of X is overrated. You can't really do pretty graphics without shared memory and/or heavy console-side logic, and if it doesn't even do sound, then what's it's advantage to a tool like VNC?
Can we also have GDB make small source-level modifications to a running binary, like Visual Studio debugger did last time I used it.
(Disclaimer: it's a few years ago, they might have removed it since.)
I actually tried to check this, but obviously I was too lazy; bash(1) doesn't seem to list true as built-in, but checking (by renaming/bin/true indeed confirms that you are right).
That title says it. It's bash syntax. Will give you about 100% CPU utilization on Linux. Run several instances at once to load more CPU's.
(while true; do true; done) &
(while true; do true; done) &
(while true; do true; done) &
Since true is/bin/true, each iteration forks twice, which means zero-filling at least a few pages of memory per iteration, which recent Linux AFAIK does with SIMD instructions where possible (someone correct me if that's not correct), so that actually loads more of the CPU core than one would think at first.
If you don't speak Japanese already, then your attempt at doing even half decent localization (assuming that includes translation) is going to futile, at least without help of someone who speaks both fluent Japanese AND fluent English.
Well, I would install it IF (and only if) I was paid enough to cover the expenses (in time and money) from backing up the box before, and restoring the box after the installation. It's not like the installation itself is that bad.:)
Recycle car, then use a bus, and suddenly you can read newspapers, books, even program with a laptop while on the road. Most importantly, you don't need to care about all the idiots on the road.:)
While I definitely agree with others that you should consult a real lawyer, it sounds to me like there's something wrong with the company.
Basicly, if someone has a dragonian IP policy, then it sounds pretty likely that they might have other dragonian policies hiding somewhere, and working for them might not be as much fun as it might sound like.
I would definitely run, but it's against my policy to advice others, so do as you see fit.:)
Slashdot Mirror
I have both Win 7 and Ubuntu running on this system (concurrently, the Ubuntu is a VirtualBox fullscreened on the second monitor), and I find your post interesting because on Windows side I have like 2 dozen icons pinned to the taskbar. Basically anything I need even semiregularly. On the Ubuntu, I have 2 icons in the Gnome panel: Firefox and gnome-terminal. I never use the Firefox icon. I think it was there by default. If I need Firefox on the Ubuntu for some reason (usually I browse with Chrome from the Windows) I'll do the same thing I do with any program other than terminal (which I usually have around 10 open on each of the 4 virtual desktops): open yet another terminal and type: firefox &
Even useless eye-candy in compiz works fine (though it's a bit slowish with RDP over interwebs). Both systems run all the time (well, the Windows needs to be booted occasionally where as KSplice deals with the Ubuntu pretty well), and they work just fine. From work-flow point of view it's mostly like working with a single system.
I also have a console switch so I can access a separate Mac (for OSX) from the same console. It works too, but it's such a pain to hop from one system to another that I usually try to avoid having to bother. What this "hot switching" sounds like is basically like using such a console switch. Doesn't sound so great when you're used to being able to just focus another window.
But it can be mitigated by using external USB drives and the 'dd' command, which allows an entire file system to be stored as an image file and then restored or even mounted temporarily.
No need to use 'dd' as you can just take a tar-ball of one filesystem. That way you don't waste space on storing (and more importantly moving) the garbage in unallocated space. There's nothing special about any of it, except whatever the bootloader (ie. grub hopefully) requires. You can use some Live ISO (usually the same one you used to copy the data over) to chroot into the system once the data is copied over and tell grub to reinstall itself (update-grub). The only other tweak required is patching new UUIDs to /etc/fstab (or you can give the old UUID to mkfs too I guess, though this could cause problems if you try to connect both drives at the same time).
I'd guess (and this is a pure guess) if you look at the life expectancy vs. attitude and quantize the attitude on a binary scale (positive thinking vs. depression) you'll see a corralation between life expectancy and positive thinking. But what happens if we compare positive attitude vs. realistic (or "average") attitude? It could be that negative attitude correlates with shortened life-expectancy, but once your attitude improves back to what can be considered "normal" there is no further advantage in being more positive. Kinda like some sort of "dimishing returns" situation?
And since we can expect Microsoft to know how to do that, we could also expect that instead of NSA, it's Microsoft that holds the backdoor to the generator in Vista. No?
And now somebody probably should say: You must be new here.
/.
Rationale: one is not supposed to RTFA on
That said, I personally kinda like legalese, patent-speak, and other dialects of formalese. They appear to be kinda like somewhere between natural and formal languages. The rules seem too strict for a truly natural language, yet not strict enough to be parsed with a formalized grammar. Most of the potential ambiguity is removed (or reduced), yet the expressive power doesn't seem to be artificially limited. If one could somehow take such a language just a couple of steps towards formalization to allow mechanical parsing and then replace the rather heavy-weight syntactical forms with something more digestible, maybe that would be an interesting basis for a semi-programming language for human-computer interaction. I mean, seriously.
Having written one or two drivers for a completely irrelevant toy operating system of mine (making me just marginally less incompetent to comment on this thread), it is very helpful to have datasheets that actually describes the operation of a given device, instead of just something like a list of it's registers and their meaning. Even descriptions of sequences of commands required are not always helpful without understanding the internal workings of the device. The resulting code ofcourse has to take all relevant device details into account, but the code itself is typically not sufficient to figure out anything beyond what the original code has at least attempted to take into consideration, if even that (ofcourse any sample code is invaluable when trying to decipher datasheets but that's another issue).
:)
So based on what little I understand about the whole subject, I'd say letting somebody develop a driver under NDA and just releasing the driver source instead of all the documentation is likely to keep a LOT more details about the device essentially secret, even if the code itself was pretty decently commented with remarks about the particular implementation (assuming ofcourse that said internal documetation isn't duplicated in the comments).
Ofcourse that DOES have the effect that anybody willing to improve the driver functionaly in regards to the device would need the same documents under NDA (or reverse-engineer the relevant details, which might be easier with a working driver to tweak), but at least a source driver let's the kernel developers deal with things like driver API changes internally. Say, you want to change the protocol by which drivers reserve IO resources because you've found a new, totally fair way to do that. Now, with binary drivers you can either break the drivers or implement workaround wrappers. Source drivers, you can simply change the driver code yourself without having a clue what the driver actually does.
I believe the root problem here is that instead of fixing just the biggest problem (address space running out), IPv6 was destined to try to solve a number of other unrelated problems, which could just as well be fixed separately if desired. I mean sure, end-to-end encryption is important in many cases, but we're doing that on application level just fine. Sure, autoconfiguration is nice, but DHCP is practically everywhere.
I mean, if all IPv6 ever did was take the IPv4 spec, multiply the length of the addresses, and set a block of the IPv6 block as the "legacy block" containing the old IPv4 network, I bet most of us would have been running this extended protocol 5 years ago, and nobody would talk much about it anymore. Slowly all software would get modified, and we could have operating systems translate the lowest level IP packets from legacy address to new ones and back to help with the transition, and gradually get application support, essentially having a functioning new network behaving the same as the old one, but with tons of unused addresses to start using when everything is ready. But no. Instead it was destined to solve the world hunger. And I thought IP was supposed to route packets.
So therefore, I will now suggest the following protocol for RFC and RFI:
---
The IPv4x4 Internet Protocol:
This new protocol family shall function exactly the same as legacy IPv4 based protocol family with the following extensions:
1. Every 4 byte field containing an IP address shall be extendeed to 4x4=16 bytes, containing an IPv4x4 address.
2. Every IPv4x4 address within the subnet 128.69.69.69.69.69.69.69.69.69.69.69.0.0.0.0/96 shall be interpreted as a legacy IPv4 address.
3. Top half of the address range (addresses with the first octed having value higher than or equal to 128) shall be reserved for future rationalisation of special block allocations. Lower half is available for normal unicast addresses, except for all zeroes which will be reserved for global broadcast and must be routed to every location including legacy IPv4 networks except where an equivalent legacy IPv4 network would fail to route such a broadcast. No other rationalisation of private blocks or multicast blocks from legacy address ranges to new ranges is done at this point.
4. Any other issues with the legacy IPv4 protocols must be addressed on protocol layers other than the IPv4x4 Internet Protocol.
----
That said, I have a strange Deja Vu... I think it must have been at least 5 years ago...
It's actually a stupid issue with pretty much all parties faulty. After reading tons of posts which all confuse it all, I did RTFKBA and RTFRFC. From the RFC and the KB article, the following facts can be found:
1. There is one flag in DHCP protocol, the "BROADCAST" flag. The "Clarifications to BOOTP (RFC 1542)" gives a nice description of it's purpose (referenced from DHCP RFC2131).
2. Normally the server sends DHCP replies as unicast packets to a specific node.
3. It is suggested there are TCP/IP implementations unable to receive such a unicast packet before they have been fully configured, in which case they should set "the flag" to request that the server sends it's reply as a broadcast instead. Server should honor such a request. I guess such an implementation would configure their local MAC (or equivalent?) at the same time with their IP level settings, which might be a sensible thing to do in a simplistic single family (IP-only) network stack, which was designed before anybody thought of "auto-configuration" things like DHCP.
4. For some unknown reason, Vista sends DHCP requests with "the flag" set by default, even if it doesn't have said inability to receive unicast packets before being fully configured.
5. A DHCP server should honor such a request, though from reading the discussion here, I futher conclude that for various reasons, maintainers of certain servers and/or networks are unwilling to support broadcast replies to DHCP requests. At least in case of centralized DHCP servers this seems a reasonable decision.
Now, it's likely that MSFT has some purpose for setting the broadcast flag (other than pissing people up). So far this purpose is more or less a mystery to me. One possible reason I can immediately think of would be allowing a DHCP server to detect the presence of another DHCP server by monitoring DHCP reply broadcasts that somebody else sent (that could be useful for certain types of "zero-config" networking maybe?). But then again they might have another reason? Who knows.. maybe they wanna start selling DHCP relays? Or maybe they want Vista users to get static IPs?
Anyway, it doesn't seem like anyone is breaking the letter of the standard, as the DHCP requests Vista's sending are technically valid (although the flag isn't set for the specific rationale it exists for), yet the servers/networks/whatever aren't really required to support the flag either (although they "should").
My hobbies include some signal processing and music production stuff, and I definitely agree with you. But I want to add, that even with cheap headphones, it tends to be easier to hear non-linearities than with speakers, especially in not-so-optimal listening conditions, because there's no reverb, and you hear each channel separately. Other subtle effects are also easier to notice (which can be a problem when listening to a headphone mix from speakers).
I personally get very annoyed nowadays when listening to commercially produced new music from headphones specifically because they often have been driven so hard through a limiter, that the effect is well past compression and sounds more like plain old-fashioned clipping.. which can be nice on individual tracks, but rarely on master.
Some amount of compression is essential for certain types of pop-music, and compressors can be used to enchance dynamics as much as reduce them; the real problem is when perfectly well sounding mixdowns are destroyed by "mastering" them with stupid amounts of "compression" essentially turning the whole track/album/whatever into a glorified pulse-width-modulation.
Yeah well, one even nowadays sees schemes like flashplayers used to stream normal mp3s over normal http connection, used to prevent people from saving the mp3s involved. Same with videos too. I'd say against normal person it's probably pretty effective. :)
That's the case, see linux manpage for random/urandom if you need a reference. ;)
I'd guess the idea is that if you are going to give each of two CPU hogs exactly 50% of CPU, you don't need an explicit timeslice as such, only some threshold of how much difference is 'unfair' enough to pre-empt the process. Say, we set the threshold at 2% then we run process A until it's got 51% of CPU, at which point we run process B until it's got 51% of CPU and so on.
For the simple case of two processes then, it seems like we have timeslices, but once stuff starts changing dynamically any "timeslice" can basicly become arbitrarily short or long.. and ofcourse we don't need to consider the threshold value at all when we consider which process to schedule, because it would only be necessary to avoid constant pre-emption when two competing tasks are already in balance.
Could ofcourse be that I've completely failed to understand the CFS concept, but the above I'd guess based on what the author explained above.
In my opinion the "safe" way of rolling a platform-independent app is to write it in ANSI C, using only standard libraries (stdio should be enough for everyone), and not expecting any special kind of terminal emulation. Granted, you need to expect a C compiler, or provide pre(hand?)compiled binaries, but platforms without acceptable C compilers tend to be old enough that you're going to have trouble finding replacement capacitors for the blown ones, let alone finding suitable replacement tubes.
If internetworking is required, pretty much every operating system comes with some form of telnet. Just don't assume any particular terminal emulation, input buffering, character encoding... Just because it's called telnet also doesn't mean it actually understands telnet commands. Backspace processing is definitely not worth it, too many different conventions there, and people should learn to type right.
If they are not convinced, explain that abbreviating saves datafile size, and hence results in faster transfers, more productive map browsing, translating directly to rising futures and/or more equal distribution of wealth.
As a long time Linux user and developer, I recently started learning a bit of Windows programming as well. It wasn't a good choice. It made me envy every single Windows developer.
Microsoft's best product ever is the Win32 API. It's somewhat sad to see that they seem to be trying to replace it with something worse. But as long as it lasts, it's pretty much the developers dream (the actual implementation might not be).
I'm probably not going to install Windows any time soon. I don't like it as a user, and I can cross-compile with Mingw on Linux just fine. Wine let's me do the initial tests, and I can use my girlfriends box to do the rest.
But I don't see myself doing that much (non-server) Linux development in the future, at least not until X is replaced with something else. Preferably with something that fits into the POSIX API. At present, mixing the two is just too painful.
PS. The network transparency of X is overrated. You can't really do pretty graphics without shared memory and/or heavy console-side logic, and if it doesn't even do sound, then what's it's advantage to a tool like VNC?
Can we also have GDB make small source-level modifications to a running binary, like Visual Studio debugger did last time I used it. (Disclaimer: it's a few years ago, they might have removed it since.)
Each riddle must be solved with oneliner in Perl.
And credit where credit is due. I admit seeing this suggestion (IIRC) on Lambda the Ultimate.
I actually tried to check this, but obviously I was too lazy; bash(1) doesn't seem to list true as built-in, but checking (by renaming /bin/true indeed confirms that you are right).
Sorry about that.
That title says it. It's bash syntax. Will give you about 100% CPU utilization on Linux. Run several instances at once to load more CPU's. (while true; do true; done) & (while true; do true; done) & (while true; do true; done) & Since true is /bin/true, each iteration forks twice, which means zero-filling at least a few pages of memory per iteration, which recent Linux AFAIK does with SIMD instructions where possible (someone correct me if that's not correct), so that actually loads more of the CPU core than one would think at first.
If you don't speak Japanese already, then your attempt at doing even half decent localization (assuming that includes translation) is going to futile, at least without help of someone who speaks both fluent Japanese AND fluent English.
Well, I would install it IF (and only if) I was paid enough to cover the expenses (in time and money) from backing up the box before, and restoring the box after the installation. It's not like the installation itself is that bad. :)
urgh.. your public transportation is ridiculously expensive.
I'd imagine it be cheaper too.
Basicly, if someone has a dragonian IP policy, then it sounds pretty likely that they might have other dragonian policies hiding somewhere, and working for them might not be as much fun as it might sound like.
I would definitely run, but it's against my policy to advice others, so do as you see fit. :)