>As far as data encryption is concerned, allow me to throw in my two cents. Keep in mind that >encryption algorythms are all breakable. Sure some can take a while to break, but they are ALL >breakable. Anyone remember the name of that Israeli optical box that broke a 512 bit crypto >key in something like 48 hours?
They may be breakable, but not within the life of the universe. The time required to brute force a 128-bit key exceeds reasonable comprehension on any normal time scale. Factoring a 1024-bit RSA key or extracting discrete logs modulo a large prime of similar size is a bit "easier", but would require a couple thousand terabytes of memory and about as much computer time as required to brute force an 80-bit symmetric key.
>A distributed calculation of pi would be cool, >but are there any algorithms to find digits of >pi without having calculated the previous >digits? If not, it can't be distributed. Yes, such algorithms exist. The Bailey-Borwein-Plouffe algorithm can compute an arbitrary digit of pi in almost linear time.
http://members.wri.com/victor/articles/pi/pi.html provides more information than one could possibly want on this topic.
I would hope that CPU resources that currently valuable or needed are not being used on distributed computing projects like these. That thought aside, pi most certainly does NOT have a repeating pattern. It is irrational (cannot be represented as a fraction of two integers) and transcendental (is not the root of any algebraic equation). The proof of the transcendence of pi is involved, but the proof of its irrationality is significantly simplier, relying on basic integration, infinite series, and one trivial property of asymtopic growth of recurrence relations.
Exciting: most people who compute work units for speed turn off the friendly screensaver, so I don't see how it's more exciting. Just kidding; I understand what you mean, but I do disagree with you. SETI is a program with a noble objective, however, it is fundementally flawed, both in implementation and premise.
Implementation: checking work units multiple times (ie. many more than would be required to detect cheater clients) because of distribution/data collection inefficiencies does not neccesary seem very productive to me Premise: Yes, it is almost certainly true that there are extraterrestial beings somewhere "out there." Nonetheless, there are two main obstacles that make it exceedingly unlikely that we will ever find anything: space and time. Space is pretty obvious; it's a big universe out there and radio signals, if any, will take a long time to propagate. Time is the big one: the probability that another civilization is at the same technological stage as us such that they use radio to communicate in astoundingly low. Just imagine: 200 hundred years ago, a mere drop in the bucket in geologic time, we could not even receive radio signals. 200 hundred years from now, whose to say that we won't be using fiber optics and laser relays to transmit information. Two cultures that are at different levels of technological accomplishment can rarely communicate or interact: look at the much smaller separation in time between the Europeans and Native Americans and the disconnect that occur then.
Seriously, I hope that they do find something. It would represent a milestone in human history that will force us to reconsider our perspective in the vast scheme of things. But I just don't think it's going to happen.
There wouldn't be any real need for a whole distributed.net scale effort to recover the CSS keys still remaining out of the 400-odd keys on the DVDs. An average computer can crack one in a matter of hours (minutes?) and certainly wouldn't take longer than a day. I think that I can probably gather enough CPU cycles to break all 400 within a week or so without much effort (gotta love stupid purchasing decisions: "Well, everybody wanted a ccNUMA machine, but since we think vector processing machines look cooler, we're budgeting for them instead, even though for your application, they're less cost-effective." Result: VPM sits unused in the corner with average load 5% since nobody wants to rewrite/recompile their code to run on it efficiently).
The comment that I am responding to is probably the most insightful one that I have read all day on Slashdot. Look beyond the lines about Microsoft, Windows 2000, Internet Explorer, and the DOJ and think about what the poster is saying generally about the economic system of free-market capitalism. Without going into a paean about its virtues, I think that it can hardly be denied that this innovation has been responsible for an era of unparalleled prosperity and technological innovation.
The previous post may not have been phrased in the most diplomatic manner possible, but to ignore its underlying message by moderating based on the overt example that he/she uses is unfair. I don't think it is a troll at all.
The Supreme Court has made a series of precedents that establish the 14th Amendment's equal protection clause as incorporating the various rights and protections in the constitution to the state and local level. If someone wants, I could look up the exact cases...
The Supreme Court has made a series of precedents that establish the 14th Amendment's equal protection clause as incorporating the various rights and protections in the constitution to the state and local level.
Nonsense. Regarding your first point, the supremacy clause allows Congress to pass laws that can supercede state or local laws in certain areas where their spheres of power interact. Regarding your second point, the 1st Amendment to the Constitution states that "Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the government for a redress of grievances." In a series of cases beginning in the early twentieth century, the Supreme Court made several precedents that essentially "incorporated" the protections in the Bill of Rights into state and local conduct based on the 14th Amendment's due process/equal protection claus: "No state shall make or enforce any law which shall abridge the privileges or immunities of citizens of the United States; nor shall any state deprive any person of life, liberty, or property, without due process of law; nor deny to any person within its jurisdiction the equal protection of the laws."
Re:The importance (or lack thereof) of uptime
on
Linux Kernel 2.2.14
·
· Score: 1
There is a difference between uptime as stored in/proc/uptime and system availability to users. Certainly, it would be nice if both could be kept up indefinitely, but real world issues prevent this from happening. If you have a server which thousands of users access, I would hope that you have some fault-tolerance mechanism is place. I would also hope that one performs the neccesary upgrades at off peak hours.
One does not need to upgrade the kernel unless: -Some major security hole has been found in a previous version of it -The new kernel contains needed functionality -The new kernel fixes some problem that affects you If the system is running correctly and there is no pressing specific reason to upgrade the kernel, one would not have to upgrade it frequently. It is not a difficult task to patch/configure/compile/replace a kernel, but the sequence of tasks is rather exactly. Just read the documentation and make sure that you have a backup of your old kernel first.
The importance (or lack thereof) of uptime
on
Linux Kernel 2.2.14
·
· Score: 5
"If your uptime isn't to sacred to ya, it may be worth upgrading."
Uptime should *never* be sacred to any computer user in the sense that preserving a high uptime should not preclude one from installing a neccessary software or hardward upgrade. What is important is that an operating system has the ability to run stably and for extended periods of time such that the use of the computer is not impaired. I've known quite a few users who claim ridiculously high uptimes (ie. > 1 year). The kernel is so out of date that any random script kiddie can grab an exploit or buffer overflow from bugtraq and root the system, obviously not a Good Thing if your computer is running any sort of critical task.
Uptime is just that: a measure of how much time has elapsed since the last reboot of the system. It does not measure any of the following things: -Superiority of an operating system -Ability to administer a computer -Programing skill -"Eliteness/coolness", whatever that is
"Inprise Corporation (Nasdaq: INPR) today announced that it is jumping to the forefront of the Linux database market by open-sourcing the beta version of InterBase 6, the new version of its SQL database. InterBase will be released in open-source form for multiple platforms, including Linux, Windows NT, and Solaris."
The press release appears to only refer to the beta version of the software. If the license is written in a particular way (ie. not open-source in the sense of the GPL or other similar license), this could exclude the use of code from the InterBase beta in other software. Although InterBase does sound very promising, I can't help but wonder if Inprise is releasing the beta for some other motive; perhaps to improve their software for free and captialize on the current craze with anything that has the word "Linux" in it (aka buzzword compliance). We'll just have to wait and see the precise terms under which Inprise is doing the "open-source" release.
I was commenting on the initial poster's invalid inference that (Windows 2000 is the most up to date version) implies (Office 2000 goes with Windows 2000). Office 2000 functions perfectly well on Windows 98, as well as Windows 95. Likewise, Office 95 functions on Windows 95, Windows 98, and Windows 2000. There is no need to upgrade to make the versions match, as the original poster states.
"For Microsoft products, it is obvious that Windows 2000 is the most up to date version, that Office 2000 goes with Windows 2000, etc., so I think that's good."
NO!!!! You can use a version of Office released in the early 90s if you want with Windows 2000. Microsoft only wants you to buy Office 2000 so that you gain the supposed benefits of "being up to date" or having the version numbers match up. This is utterly ridiculous; if your version of Office does what you need it to do, then why bother getting Office 2000 to get the same number as the operating system. In this context, a year version means absolutely NOTHING; it is used to deliberately [yes, split infinitive] create the false impression that one must upgrade (at a fee, of course) to get the full benefits of the new operating system.
Traditional version numbers make sense IF you know about the software that you are using. Computers are not black box, consumer appliances in the same sense as cars. Sure, it would be great if they were easier for a novice to use, however, several important differences exist. First among them, the differences among cars from varying years is practically *non-existent* while computers and software [should] have meaningful changes and improvements between versions.
Your analogy is flawed, as is your premise that year-based versioning is neccesarily or intrinsically superior to other versioning systems.
There is nothing intrinsically wrong with versioning based on the year, with subversions and revisions on each major version change as long as the versioning system does not affect the quality/timing of releases, encourage unneccesary releases, AND each release is clearly and unambigiously distinguishable from each other, with the chronological progression and extent of changes between releases obvious.
I think that basing the main version number of a piece of software is sometimes a very logical idea. It gives an intuitive understanding of the time period in which a software release occurred, unlike, for example, the Linux kernel versioning system.
Which is not to say that version numbers based on years are always good. Witness Windows 95 and 98 and the games MS played with OSR releases, OEM versions, Second Edition, Retail releases, etc.
If the foo is a pointer to an object of type int, the operator += acts on foo as a pointer expression. The result of the additive operator has type pointer to type int as well. Section 6.5.6, item 8 of the ISO C standard clearly indicates that "When an expression that has integer type is added to or subtracted from a pointer, the result has the type of the pointer operand...In other words, if the expression P points to the i-th element of an array object [see 6.5.6 item 4 for implicit conversion], the expressions (P)+N (equivalently, N+(P)) and (P)-N (where N has the value n) point to, respectively, the i+n-th and i-n-th elements of the array object, provided they exist." 6.5.2.1 item 4 states that "In the expression (*((x)+(i))...i is adjusted according to the type of x, which conceptually entails multiplying i by the size of the object to which the pointer points" Combined, this indicates that foo+=4 has a very different meaning than foo+=sizeof(int) even if sizeof(int)==4 and the type of foo is a pointer to type int. The type of time_t is implementation defined; it does not have to be a long. __time_t is in the reserved namespace of the implementor; the programmer should not use this identifier.
Oh well, that was my first language lawyer comment of the new millenium.
Sure, it's a new technological toys that I'm sure we'd all like to have. But is it really commercially viable? A wireless service and being able to use TCP/IP applications is great and all, but how much will the service cost once it leaves beta? Per byte or per minutes fees will certainly detract from the utility of the service, but I suppose it'll all be a matter of how much the market can bear and what the wireless provider will charge for access fees. Does anyone have any numbers?
The genetically altered bacteria Deinococcus radiodurans does not consume radioactive compounds as the summary suggests. As physics assures us, it is [almost] impossible to alter the half-life of a radioactive compound or transmutate elements without massive equipment. OTOH, what these bacteria do is that they have been genetically customized to transform highly reactive heavy metal compounds into more tame and benign materials. The "radiodurans" part of the name refers to the fact that the bacteria can withstand "1.5 million rads of gamma radiation, or about 3,000 times the lethal dose for humans." Pretty amazing stuff.
The longest distance I've ever tried was about 3km using equipment that's a year or two old so your results may vary. Anyway to get back to the subject, LoS considerations are quite important even though microwave or RF systems don't technically need for there to be a clear visual path. If you don't have a good LoS between the receiver and the transmitter, you are at the mercy of wave piping effects and greater potential power dispersion/interferece. A directional system is definitely better than omnidirectional systems, but they are slightly harded to set up. I don't know about any special conditions that a metropolitan area might impose, although a reasonable guess would be the greater saturation in noise level might require more transmitter power.
In certain subtle, but certaintly quantifable ways, C's use as a language for large-scale non-systems programming applications had already begun to wane with the advent of a) a standard for C++ that most compilers reasonably complied with and b) improvement in computer speed such that squeezing that last cycle out of a loop isn't that neccesary for most applications. While there are some exceptions, most GUI developement widget sets/packages are intrinsically object-oriented, and as such, IMHO, the use of C for them would, in most cases, be detremental to coding clarity and efficiency. C is a great language, but it lacks even the lamentably week type checking of C++, not to say more strongly typed languages.
Considering the availability of easy to use, secure, persistent, pseudoanonymous nyms (http://www.freedom.com) and the increasing role that electronic commerce plays in our economy, what privacy and security concerns do you anticipate moving to the forefront of attention as this rapidly changing technology evolves?
Is it inevitable that Linux one day become obselete and cosequently be superceded by the Next Great OS? The obvious answer to this question is yes: all things must eventually come to an end and computing is not a field where any one technique can retain supremacy in the face of continual technical improvement. The equally obvious reply is that the methodology process used in Linux and other open-source operating systems such as *BSD and Hurd represent a new paradigm in software developement that self-perpetuates itself and adapts to new advances by incorporating them into its own infrastructure while creating new innovation. What view do you subscribe to?
hash include lessthan stdio dot h greaterthan feed feed int main open void close feed curlyopen feed indent-one printf open quotes h e l l o comma space w o r l d backslash n quotes close semicolon feed back-one curlyclose feed
hello.c:4:warning: main() declared as returning type 'int' but does not return expected type
Slashdot Mirror
>As far as data encryption is concerned, allow me to throw in my two cents. Keep in mind that
>encryption algorythms are all breakable. Sure some can take a while to break, but they are ALL
>breakable. Anyone remember the name of that Israeli optical box that broke a 512 bit crypto
>key in something like 48 hours?
They may be breakable, but not within the life of the universe. The time required to brute force a 128-bit key exceeds reasonable comprehension on any normal time scale. Factoring a 1024-bit RSA key or extracting discrete logs modulo a large prime of similar size is a bit "easier", but would require a couple thousand terabytes of memory and about as much computer time as required to brute force an 80-bit symmetric key.
>A distributed calculation of pi would be cool,
>but are there any algorithms to find digits of
>pi without having calculated the previous
>digits? If not, it can't be distributed.
Yes, such algorithms exist. The Bailey-Borwein-Plouffe algorithm can compute an arbitrary digit of pi in almost linear time.
http://members.wri.com/victor/articles/pi/pi.html provides more information than one could possibly want on this topic.
I would hope that CPU resources that currently valuable or needed are not being used on distributed computing projects like these. That thought aside, pi most certainly does NOT have a repeating pattern. It is irrational (cannot be represented as a fraction of two integers) and transcendental (is not the root of any algebraic equation). The proof of the transcendence of pi is involved, but the proof of its irrationality is significantly simplier, relying on basic integration, infinite series, and one trivial property of asymtopic growth of recurrence relations.
Try http://www.seanet.com/~ksbrown/kmath313.htm
Exciting: most people who compute work units for speed turn off the friendly screensaver, so I don't see how it's more exciting.
Just kidding; I understand what you mean, but I do disagree with you. SETI is a program with a noble objective, however, it is fundementally flawed, both in implementation and premise.
Implementation: checking work units multiple times (ie. many more than would be required to detect cheater clients) because of distribution/data collection inefficiencies does not neccesary seem very productive to me
Premise: Yes, it is almost certainly true that there are extraterrestial beings somewhere "out there." Nonetheless, there are two main obstacles that make it exceedingly unlikely that we will ever find anything: space and time. Space is pretty obvious; it's a big universe out there and radio signals, if any, will take a long time to propagate. Time is the big one: the probability that another civilization is at the same technological stage as us such that they use radio to communicate in astoundingly low. Just imagine: 200 hundred years ago, a mere drop in the bucket in geologic time, we could not even receive radio signals. 200 hundred years from now, whose to say that we won't be using fiber optics and laser relays to transmit information. Two cultures that are at different levels of technological accomplishment can rarely communicate or interact: look at the much smaller separation in time between the Europeans and Native Americans and the disconnect that occur then.
Seriously, I hope that they do find something. It would represent a milestone in human history that will force us to reconsider our perspective in the vast scheme of things. But I just don't think it's going to happen.
There wouldn't be any real need for a whole distributed.net scale effort to recover the CSS keys still remaining out of the 400-odd keys on the DVDs. An average computer can crack one in a matter of hours (minutes?) and certainly wouldn't take longer than a day. I think that I can probably gather enough CPU cycles to break all 400 within a week or so without much effort (gotta love stupid purchasing decisions: "Well, everybody wanted a ccNUMA machine, but since we think vector processing machines look cooler, we're budgeting for them instead, even though for your application, they're less cost-effective." Result: VPM sits unused in the corner with average load 5% since nobody wants to rewrite/recompile their code to run on it efficiently).
The comment that I am responding to is probably the most insightful one that I have read all day on Slashdot. Look beyond the lines about Microsoft, Windows 2000, Internet Explorer, and the DOJ and think about what the poster is saying generally about the economic system of free-market capitalism. Without going into a paean about its virtues, I think that it can hardly be denied that this innovation has been responsible for an era of unparalleled prosperity and technological innovation.
The previous post may not have been phrased in the most diplomatic manner possible, but to ignore its underlying message by moderating based on the overt example that he/she uses is unfair. I don't think it is a troll at all.
The Supreme Court has made a series of precedents that establish the 14th Amendment's equal protection clause as incorporating the various rights and protections in the constitution to the state and local level. If someone wants, I could look up the exact cases...
The Supreme Court has made a series of precedents that establish the 14th Amendment's equal protection clause as incorporating the various rights and protections in the constitution to the state and local level.
Nonsense. Regarding your first point, the supremacy clause allows Congress to pass laws that can supercede state or local laws in certain areas where their spheres of power interact.
Regarding your second point, the 1st Amendment to the Constitution states that "Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the government for a redress of grievances." In a series of cases beginning in the early twentieth century, the Supreme Court made several precedents that essentially "incorporated" the protections in the Bill of Rights into state and local conduct based on the 14th Amendment's due process/equal protection claus: "No state shall make or enforce any law which shall abridge the privileges or immunities of citizens of the United States; nor shall any state deprive any person of life, liberty, or property, without due process of law; nor deny to any person within its jurisdiction the equal protection of the laws."
There is a difference between uptime as stored in /proc/uptime and system availability to users. Certainly, it would be nice if both could be kept up indefinitely, but real world issues prevent this from happening. If you have a server which thousands of users access, I would hope that you have some fault-tolerance mechanism is place. I would also hope that one performs the neccesary upgrades at off peak hours.
One does not need to upgrade the kernel unless:
-Some major security hole has been found in a previous version of it
-The new kernel contains needed functionality
-The new kernel fixes some problem that affects you
If the system is running correctly and there is no pressing specific reason to upgrade the kernel, one would not have to upgrade it frequently. It is not a difficult task to patch/configure/compile/replace a kernel, but the sequence of tasks is rather exactly. Just read the documentation and make sure that you have a backup of your old kernel first.
"If your uptime isn't to sacred to ya, it may be worth upgrading."
Uptime should *never* be sacred to any computer user in the sense that preserving a high uptime should not preclude one from installing a neccessary software or hardward upgrade. What is important is that an operating system has the ability to run stably and for extended periods of time such that the use of the computer is not impaired. I've known quite a few users who claim ridiculously high uptimes (ie. > 1 year). The kernel is so out of date that any random script kiddie can grab an exploit or buffer overflow from bugtraq and root the system, obviously not a Good Thing if your computer is running any sort of critical task.
Uptime is just that: a measure of how much time has elapsed since the last reboot of the system. It does not measure any of the following things:
-Superiority of an operating system
-Ability to administer a computer
-Programing skill
-"Eliteness/coolness", whatever that is
"Inprise Corporation (Nasdaq: INPR) today announced that it is jumping to the forefront of the Linux database market by open-sourcing the beta version of InterBase 6, the new version of its SQL database. InterBase will be released in open-source form for multiple platforms, including Linux, Windows NT, and Solaris."
The press release appears to only refer to the beta version of the software. If the license is written in a particular way (ie. not open-source in the sense of the GPL or other similar license), this could exclude the use of code from the InterBase beta in other software. Although InterBase does sound very promising, I can't help but wonder if Inprise is releasing the beta for some other motive; perhaps to improve their software for free and captialize on the current craze with anything that has the word "Linux" in it (aka buzzword compliance). We'll just have to wait and see the precise terms under which Inprise is doing the "open-source" release.
I was commenting on the initial poster's invalid inference that (Windows 2000 is the most up to date version) implies (Office 2000 goes with Windows 2000). Office 2000 functions perfectly well on Windows 98, as well as Windows 95. Likewise, Office 95 functions on Windows 95, Windows 98, and Windows 2000. There is no need to upgrade to make the versions match, as the original poster states.
"For Microsoft products, it is obvious that Windows 2000 is the most up to date version, that Office 2000 goes with Windows 2000, etc., so I think that's good."
NO!!!! You can use a version of Office released in the early 90s if you want with Windows 2000. Microsoft only wants you to buy Office 2000 so that you gain the supposed benefits of "being up to date" or having the version numbers match up. This is utterly ridiculous; if your version of Office does what you need it to do, then why bother getting Office 2000 to get the same number as the operating system. In this context, a year version means absolutely NOTHING; it is used to deliberately [yes, split infinitive] create the false impression that one must upgrade (at a fee, of course) to get the full benefits of the new operating system.
Traditional version numbers make sense IF you know about the software that you are using. Computers are not black box, consumer appliances in the same sense as cars. Sure, it would be great if they were easier for a novice to use, however, several important differences exist. First among them, the differences among cars from varying years is practically *non-existent* while computers and software [should] have meaningful changes and improvements between versions.
Your analogy is flawed, as is your premise that year-based versioning is neccesarily or intrinsically superior to other versioning systems.
There is nothing intrinsically wrong with versioning based on the year, with subversions and revisions on each major version change as long as the versioning system does not affect the quality/timing of releases, encourage unneccesary releases, AND each release is clearly and unambigiously distinguishable from each other, with the chronological progression and extent of changes between releases obvious.
I think that basing the main version number of a piece of software is sometimes a very logical idea. It gives an intuitive understanding of the time period in which a software release occurred, unlike, for example, the Linux kernel versioning system.
Which is not to say that version numbers based on years are always good. Witness Windows 95 and 98 and the games MS played with OSR releases, OEM versions, Second Edition, Retail releases, etc.
If the foo is a pointer to an object of type int, the operator += acts on foo as a pointer expression. The result of the additive operator has type pointer to type int as well. Section 6.5.6, item 8 of the ISO C standard clearly indicates that "When an expression that has integer type is added to or subtracted from a pointer, the result has the type of the pointer operand...In other words, if the expression P points to the i-th element of an array object [see 6.5.6 item 4 for implicit conversion], the expressions (P)+N (equivalently, N+(P)) and (P)-N (where N has the value n) point to, respectively, the i+n-th and i-n-th elements of the array object, provided they exist."
6.5.2.1 item 4 states that "In the expression (*((x)+(i))...i is adjusted according to the type of x, which conceptually entails multiplying i by the size of the object to which the pointer points"
Combined, this indicates that foo+=4 has a very different meaning than foo+=sizeof(int) even if sizeof(int)==4 and the type of foo is a pointer to type int. The type of time_t is implementation defined; it does not have to be a long. __time_t is in the reserved namespace of the implementor; the programmer should not use this identifier.
Oh well, that was my first language lawyer comment of the new millenium.
...
Sure, it's a new technological toys that I'm sure we'd all like to have. But is it really commercially viable? A wireless service and being able to use TCP/IP applications is great and all, but how much will the service cost once it leaves beta? Per byte or per minutes fees will certainly detract from the utility of the service, but I suppose it'll all be a matter of how much the market can bear and what the wireless provider will charge for access fees. Does anyone have any numbers?
The genetically altered bacteria Deinococcus radiodurans does not consume radioactive compounds as the summary suggests. As physics assures us, it is [almost] impossible to alter the half-life of a radioactive compound or transmutate elements without massive equipment. OTOH, what these bacteria do is that they have been genetically customized to transform highly reactive heavy metal compounds into more tame and benign materials. The "radiodurans" part of the name refers to the fact that the bacteria can withstand "1.5 million rads of gamma radiation, or about 3,000 times the lethal dose for humans." Pretty amazing stuff.
The longest distance I've ever tried was about 3km using equipment that's a year or two old so your results may vary. Anyway to get back to the subject, LoS considerations are quite important even though microwave or RF systems don't technically need for there to be a clear visual path. If you don't have a good LoS between the receiver and the transmitter, you are at the mercy of wave piping effects and greater potential power dispersion/interferece. A directional system is definitely better than omnidirectional systems, but they are slightly harded to set up. I don't know about any special conditions that a metropolitan area might impose, although a reasonable guess would be the greater saturation in noise level might require more transmitter power.
In certain subtle, but certaintly quantifable ways, C's use as a language for large-scale non-systems programming applications had already begun to wane with the advent of a) a standard for C++ that most compilers reasonably complied with and b) improvement in computer speed such that squeezing that last cycle out of a loop isn't that neccesary for most applications. While there are some exceptions, most GUI developement widget sets/packages are intrinsically object-oriented, and as such, IMHO, the use of C for them would, in most cases, be detremental to coding clarity and efficiency. C is a great language, but it lacks even the lamentably week type checking of C++, not to say more strongly typed languages.
Considering the availability of easy to use, secure, persistent, pseudoanonymous nyms (http://www.freedom.com) and the increasing role that electronic commerce plays in our economy, what privacy and security concerns do you anticipate moving to the forefront of attention as this rapidly changing technology evolves?
Is it inevitable that Linux one day become obselete and cosequently be superceded by the Next Great OS? The obvious answer to this question is yes: all things must eventually come to an end and computing is not a field where any one technique can retain supremacy in the face of continual technical improvement. The equally obvious reply is that the methodology process used in Linux and other open-source operating systems such as *BSD and Hurd represent a new paradigm in software developement that self-perpetuates itself and adapts to new advances by incorporating them into its own infrastructure while creating new innovation. What view do you subscribe to?
hash include lessthan stdio dot h greaterthan feed feed int main open void close feed curlyopen feed indent-one printf open quotes h e l l o comma space w o r l d backslash n quotes close semicolon feed back-one curlyclose feed
hello.c:4:warning: main() declared as returning type 'int' but does not return expected type