Sure, your networked rifle squad could lose its GPS uplink--but that's no different than having your map burnt away from you.
Nonsense. It's far easier (though still
difficult, obviously) to shoot down a dozen
satellites - or just jam their transmissions
effectively - than to find each paper map in
an enemy army of 100,000 troops and burn them.
Need to reproduce a map? Find a photocopy
machine, or make a quick sketch by hand!
Technology is great, but it's not without
risks. The warning against over-reliance on
technology is a valid one.
It's really much more involved than the plug-'n-play 10baseT that we've all gotten used to with the dominance of Ethernet.
10BaseT also required extra hardware, in the
form of a hub or switch. Unswitched ethernet
is also susceptible to many similar problems,
such as a single broken or malicious node that
won't stop transmitting. Older readers may
remember how expensive ethernet switches were,
which is why some sites were forced to deal
with the nightmare that is 10Base2.
Not really. A "hate crime" is really just a
new category of intentions for the same
actions that society thinks should be punished
differently. For example, it's very
different to kill your wife immediately after
finding her in bed with another man, than to
kill your wife two weeks later, after purchasing
a $5M life insurance for her. The value of
your wife's life has not changed over those
two weeks, but the mitigating circumstances
to the killing have.
damages awarded as zero, or $1, could go with an injunction against using GPLed code in the future, and that would be enough.
No, that wouldn't be enough. That's saying
that any commercial entity can just steal
GPL code at will, and pay $1 if they're
found out.
If the original authors are giving away
the code for free, it's a bit hard to calculate
compensatory damages. However, punitive
damages should be assessed, so that companies
don't get away with the act. Either they
should be required to remove the offending
code (incurring large delays in their product
cycle from having to develop an alternative)
with a smaller fine, or provide the modified
sources with a bigger fine (so they don't think
they can just delay open sourcing until sued).
For example, if management has given a team a 6 month time frame, and the team thinks the product should start testing in 3 months, they may have a better chance at getting the product to SQA by using Java, Perl, or VB instead of C.
I don't have a problem with your general
suggestion of using the right tool for the
job. However, in this example, you are
assuming that your development team is
equally competent at the language and tools
of each choice. This is a big and almost
always invalid assumption. Particularly for
a 3-month development project, the best tool
is probably the one you already know best.
In Java, dividing by 0 gives me an exception that I can catch (and a stack trace if I don't catch it).
Java (or an interpreted language) would not
crash the way a C program might. That wasn't
my assertion. The point is, division by zero
is a logic bug that the programmer must handle.
No language is going to do that for you
appropriately.
In this case, an end user would rightfully
consider a stack trace to be a bug.
The features of the language of my choice makes a big difference in both debugability and robustness.
Most of the time, ease of debugging is a
feature of the implementation, not the
language. A C interpreter can easily tell
you exactly which line of code caused the
division by zero. A compiled C implementation
can also note the instruction that caused the
division by zero, and work back out to a line
of source code.
There are different aspects of robustness.
In the Java sense, you're probably referring
the underlying platform protecting the system
against errant programs. That's a great
feature (which has a trade-off, of course),
but Java programs are not inherently robust
in the sense of handling user input correctly.
Note that running a C program in a virtual
machine, for example, has a similar effect.
It would be interesting to do a study of the "bugginess" of programs written in python, java, scheme, smalltak, lisp etc. My guess is that programs written in C crash the most.
Even that is a worthless statistic. Assuming that bad
programs are written by bad programmers, the
language that more bad programmers choose will
appear the highest in your study as the buggiest
language. Bad programmers choose the language du
jour, thinking it will land them a cushy job.
You'll have to disprove the assumption to correctly
blame the language.
Use better languages and crash less.
Try dividing by zero in your better language of
choice.
If it weren't for Quallcom's patents on CDMA, nobody would be using GSM which is based on TDMA.
This is not wholly accurate. TDMA is old,
obvious, and proven technology, requiring
nothing more complicated than a uniform source
of timing, and is possibly less demanding on
the handset hardware than CDMA.
Telecommunications carriers tend to be
conservative, because the upfront investments
are astronomical.
Secondly, according to Qualcomm's own
information, CDMA by 1995 offered only 10x
improvement (over analog cellular) of the
bandwidth utilization. By contrast, TDMA
offers somewhere from 3x to 8x, so the case
for ripping out all your expensive network
hardware is not as compelling back then.
Today in Iraq, starting from scratch, the
equation is obviously different. When GSM's
time comes, however, it should be remembered
as a reliable workhorse, not something that
was always inferior to CDMA except for patents.
GSM was the first mobile phone system that
offered global roaming, a feature taken for
granted today, but causing so many problems
back then that several horribly expensive
satellite based solutions were built.
SIMM card
Only one "M". It stands for "Subscriber
Identity Module".
It's as if I give you an old table I found in my basement, and you find a gold bar in one of the legs. Can I sue you to get it back because I didn't know that it was there? No, because it's yours and myfault for not inspecting the table beforehand to ensure I was only giving away the table.
Possibly. Let's modify the analogy to suit the
case a little better.
Let's say the table has a secret compartment,
just like a large base of code like a Linux
distribution is nearly impossible to inspect
thoroughly. Let's say another person stole
your bar of gold from your safe, and hid it
in the table that you gave me.
What do you think now? Should you suffer the
loss of that gold bar?
So what you're really saying is that you want stronger environmental enforcement, regulations that favor less strenuous work-weeks, and corporate executives that think long-term.
No, I'm really not. What I'd like to see is a
more moderate form of capitalism, coming not
from external pressures and regulation, but
from internal philosophy. I'd like to see profit
remain a goal, because economic growth really
is important, and competition really does keep
companies on their toes and makes things better.
The problem I have is that today, profits need
to be maximized. $13B in profits is
infinitely better than $12.5B. So much better
that it's worth laying 30,000 people for. I'm
talking about capitalists - most of them, at
least - becoming more content with the returns
on their investments.
I'm not only talking about the rich people.
When we sign up for your 401(k) (US pre-tax
retirement investment plan), and we only look
at the ROI number, we're part of the problem.
Last, but not least, if the current system really bothers you that much, join a commune or "slack".
I don't want to do that. I enjoy working and
making a good living. I just don't want to be
pursuing the last dollar or cent I can get my
hands on, ignoring everything I have to do to
get it.
Capitalism, OTOH, is where the government establishes a framework in which a sufficient number of individual actors compete to provide goods and services, but without forming enough power to become market-states.
That isn't enough, and we're beginning to see hints of
what's lacking in our culture.
Even in competitive Capitalism, the end goal is to
maximize profit. Profit is not a bad thing, but the
maximization of profit often brings about bad side
effects. Companies dumping toxic waste into the
river, lying executives, laying off many and overworking
the rest, etc. Many of these are not only harmful to
its employees and neighbors, but to the long term
viability of the company itself. The need to look good
in a quarterly report can drive an otherwise sane
company to near suicidal stunts like shipping products
before they are ready.
I'm not intelligent enough to have an alternative. I
just would like to see a more moderate version where
corporations can be content with some profit, and
not have to squeeze every near-term dollar out of
its employees, customers, and neighbors.
profits before people isn't just immoral and unethical, it's disgusting.
This is a beautiful sentence. It really is.
You imply that "disgusting" is worse than "immoral
and unethical". Molds in your refrigerator are
disgusting. Immoral and unethical should be much
worse than fungal growths, which after all give us
penicillin.
The problem is that it isn't. I know you don't mean it
that way, but your sentence almost reads as if it's
okay if you're immoral and unethical, as long as you're
not disgusting. Which is exactly what's wrong with
the world.
Even more effected by this are third world countries who will be completely at the mercy of these companies.
It's worse than that. All Monsanto really wants is profit,
so "mercy" in this case can simply be purchased with
dollars. (Yes, I'm being sarcastic.)
The problem is a global monoculture of food crops. As
smart as Monsanto's scientists are, they cannot predict
every possible attack. Planting an entire country full of
identical crops, however, is just waiting for disaster,
either from nature or from a terrorist biological attack.
We're talking mass starvation and subsequent breakdown
of entire societies, not just economic dependency.
It is well known that people who are very intelligent also tend to have excellent social skills and a good sense of humour. If anything, too good -- that's the real reason they might not fit in so well.
Hmm?
Social skills are measured by how many human
situations one can harmoniously fit into. For example,
if you're well liked among geeks, jocks, and bikers,
then you might have good social skills. If you're only
accepted among geeks who play a particular board
game, then you might not have very good social
skills. I don't understand how or why you are separating
the two.
(I don't know who David Arthur is, and I'm not talking
about him.)
I like Windows and abandoned Macs somewhere around '91 for many reasons but mainly value for the dollar.
This value comes at a price. You helped create a
monoculture of operating systems, where
interoperability is possible essentially only when
Microsoft was late to the party, where a single virus
outbreak may take down most of the world's
connected desktops, and where one company decides
where you want to go today.
I like Apple, but I wouldn't want to see Apple with
95% of the market either. What I want is diversity,
where several competing platforms capture various
niches, none able to dominate the others.
Funny you should mention value for the dollar. You
do realize that Microsoft can probably sell Windows at
$10 a copy and still make money, right?
what good is this on an OS that can't handle opening as many windows as I can manage with a 2d interface?
Did you actually read my post?
The OS is not the problem. It can handle many more
windows than any person can. It's the 2-D desktop
metaphor that's limiting us today.
What good is it for anyone who actually closes windows they aren't using?
Why should you have to close it? You're so conditioned
to the way you work that you can't "zoom out" and
consider that there may be other ways to get things
done.
You may know of people who appear messy, because
they have stacks of papers all over their desk. However,
some of these people can easily find what they need,
despite the apparent mess. These people are able to
remember chronologically and spatially where their
documents are. A 3-D desktop like I mentioned may
actually find a document faster than the traditional
nested folders option.
Seriously, I've never known anyone who actually needed more than 8-12 windows at a time and those are power users
Has it ever occurred to you that maybe it's not that they
couldn't use more open windows so much as they
can't handle so many open ones, under the current
metaphor of the 2-D desktop?
If you observe a user of Apple ][ in 1982 or so, you'll
notice that even power users only used one task.
If you concluded that even power users only need
one task, you'd be wrong. How about circa Windows 3.1?
People had multiple windows, but you couldn't really
have all that many open, because screen resolutions
were poor.
This again is a wasted resource.
Try to be open minded. Have you ever even used a
3-D desktop like I described? Besides, if you paid
attention, you'd realize that almost all of the work is
done by my very idle 3-D GPU.
However, for user interfaces 3d is bad unless it's a hologram
Let me give you an example.
First, imagine your current desktop as having
depth. Each window is a different distance
from you, and windows that are "nearer" to you
can obscure windows that are "farther". If
you are constrained to looking at your stack
of windows from one direction (the front),
then visually that's what you have today.
One limitation of this is that you cannot
really have too many windows. Windows in the
"back" can be hard to get to, and bringing
them "in front" can obscure other things
you want. In other words, we have a space
management problem, and the granularity is
the window.
Now, imagine if you rotated that view 90
degrees to the left or right, and assume
that your windows are one pixel "thick".
You'd expect to see a number of vertical
lines, each representing a window. This
view is pretty useless, because you'll have
a hard time figuring out which window is
which. However, it does sudden show all
of your windows.
Where does 3-D come in? It lets you rotate
your desktop at any angle between 0 (in
front) and 90 degrees to the left or right.
This allows you to take peeks behind the
top windows, without actually bringing the
rear windows forward. To improve the
effect, "near" windows can become more
transparent as the viewing angle increases,
showing more of what's behind.
How do you control that? Very
easily. If you have a multi-button mouse,
you can hold down one special button and
move the mouse in any direction to rotate
the desktop in that direction. Let go of
the mouse button, and the display snaps
back to the "in front" view.
It's not going to change the world, obviously,
but I think this may enable people to
effectively use more windows than before.
Re:Excellent!
on
Gentoo Games
·
· Score: 1, Insightful
they are competent coders and they know what the average Linux user wants, because they ARE your average Linux users.
I don't think that's accurate. Average Linux
users don't want to build everything from
source. They use binary distros.
Hm.Let's say i has value 3. = has associativity right to left. So the expression on RHS should be evaluated first:
Please read my post again, or find yourself an
authoritative reference in C. In C, the
order of evaluation is essentially undefined,
except at sequence points, where all previous
expressions and side effects are fully
evaluated. Accessing and modifying an object
separately between two sequence points is
undefined behavior.
It has nothing to do with associativity,
which only means anything if your C statement
doesn't invoke undefined behavior.
However my compilers disagree with each other.
Not only that, your compiler may disagree
with itself depending on whether optimizations
are enabled or not. This is because you
invoked undefined behavior, for which no
particular result can be expected.
Re:Gaming the Recorder and Black Boxes
on
DVRs for Cop Cars
·
· Score: 1
What if the police could show from a EKG strip that the cop really was scared for his life?
That's probably going too far. An EKG might
show excitement, but AFAIK cannot distinguish
between fear and other emotions such as anger.
In any case, if such an incident came to trial,
the relevant evidence is whether the officer
obeyed procedures, and whether a reasonable
person should fear for his or her life. If
the officer was unreasonably scared, he or
she will still be guilty of misuse of force
or whatever.
Re:gcc 3.3 fails on glibc 2.3.2
on
GCC 3.3 Released
·
· Score: 1
It's not necessarily someone who doesn't know the language. Sometimes "normal" mistakes happen and don't get corrected because nobody noticed (i.e. because the compiler generated code that didn't expose the bug).
I see. I was confused by the way you phrased
the statement, which made it sound like there
were many cases of relying on compiler quirks
without meaning to, which is just sloppy. Bugs
are of course a fact of life, but they should
be few and far in between for a mature product
like Linux.
The IRS is perfectly capable of allowing consumers to file online tax returns.
[...] There's no reason for them not to,
except for frantic lobbying by certain
interests.
You're not alone. It doesn't even have to be
a real tax preparation software or website.
How about just an Excel spreadsheet template
that I can fill in, and email to them?
Security minded? How about a secure website
I can upload the spreadsheet to? These are
things that will take literally a few hours
to do.
If I don't feel like spending for tax
software, why should I have to do all that
stupid arithmetic when I have three computers
in the house?
since it was problem prone, I changed it the days that followed
Now that you understand the problem, I strongly
suggest you acquire an authoritative reference
for C or C++, whichever you are using. If you
can read the ISO standard, that's obviously the
best resource. Electronic copies are available
for about $20, I think.
What you did was rely on something the language
never guaranteed. C defines a concept called
a sequence point (mainly the ';' at the end
of a statement, but there are other sequence points),
at which point all previous expressions would
have been fully evaluated. Between two
sequence points, however, it guarantees
nothing. So, this:
a[i] = i++;
is undefined, because since '=' is not a
sequence point, you don't know which value
of 'i' will be used to get a[i]. In fact,
as you've found out, it can differ between
debug and release builds. On the other
hand, this:
a[i] = i; i++;
is valid C code, because ';' is a sequence
point, and 'i' is not both modified and
accessed between two sequence points. C++
basically inherits all of this from C.
Sequence points in C is a level of understanding
that should give you chills thinking back at
every line of code you've ever written.
When I arrived at SAGEM, progammers wereeven releasing Debug versions of their programs, because they didn't want to spend time on finding why release mode was not working
That's just sloppy. A difference in behavior
between debug and release builds can be an
indicator of major bugs that are merely
better hidden by the debug version. The bug
may still surface when the program is
subjected to real world loads, or some
unexpected input. It's possible that a
compiler bug causes the release build to be
broken, and so you ship the debug build, but
not investigating is plainly irresponsible.
Re:nonnull function attribute
on
GCC 3.3 Released
·
· Score: 3, Interesting
Seems useful, though I suspect many derefernced pointers are set NULL at runtime, and so not spottable during build.
It's possible to check at compile time. It's
not so much that the compiler detects whether
a parameter is null or not at compile time,
but whether it can be. For example:
can trigger a warning or error, because
malloc() does not return a "nonnull"
pointer, and so passing p to do_work is
dangerous. On the other hand, given the
code:
then the compiler can work out that the call
is safe. This is how LCLint, for example,
can do with its/*@null@*/ attribute. The
logic will be a little like tracing whether
a const variable is passed to a function
expecting a non-const parameter. I don't
know how far gcc plans to take this feature.
Re:gcc 3.3 fails on glibc 2.3.2
on
GCC 3.3 Released
·
· Score: 1
This is because many kernel rely (unintentionally) on some behaviour of gcc that is not guaranteed by the standard.
Really? I would consider that to be terrible
code. It's one thing to intentionally rely on
compiler quirks, because sometimes you really
don't have a choice. It's another entirely to
not even know that your code relies on a
particular version of the compiler. An
unintended portability problem is a bug,
produced by a programmer who doesn't know
his or her language!
Absent proof of many portability bugs in
Linux, I don't think your assertion can
stand.
Slashdot Mirror
Nonsense. It's far easier (though still difficult, obviously) to shoot down a dozen satellites - or just jam their transmissions effectively - than to find each paper map in an enemy army of 100,000 troops and burn them. Need to reproduce a map? Find a photocopy machine, or make a quick sketch by hand!
Technology is great, but it's not without risks. The warning against over-reliance on technology is a valid one.
Sorry, what extra hardware are you referring to?
It's really much more involved than the plug-'n-play 10baseT that we've all gotten used to with the dominance of Ethernet.
10BaseT also required extra hardware, in the form of a hub or switch. Unswitched ethernet is also susceptible to many similar problems, such as a single broken or malicious node that won't stop transmitting. Older readers may remember how expensive ethernet switches were, which is why some sites were forced to deal with the nightmare that is 10Base2.
Not really. A "hate crime" is really just a new category of intentions for the same actions that society thinks should be punished differently. For example, it's very different to kill your wife immediately after finding her in bed with another man, than to kill your wife two weeks later, after purchasing a $5M life insurance for her. The value of your wife's life has not changed over those two weeks, but the mitigating circumstances to the killing have.
No, that wouldn't be enough. That's saying that any commercial entity can just steal GPL code at will, and pay $1 if they're found out.
If the original authors are giving away the code for free, it's a bit hard to calculate compensatory damages. However, punitive damages should be assessed, so that companies don't get away with the act. Either they should be required to remove the offending code (incurring large delays in their product cycle from having to develop an alternative) with a smaller fine, or provide the modified sources with a bigger fine (so they don't think they can just delay open sourcing until sued).
I don't have a problem with your general suggestion of using the right tool for the job. However, in this example, you are assuming that your development team is equally competent at the language and tools of each choice. This is a big and almost always invalid assumption. Particularly for a 3-month development project, the best tool is probably the one you already know best.
Java (or an interpreted language) would not crash the way a C program might. That wasn't my assertion. The point is, division by zero is a logic bug that the programmer must handle. No language is going to do that for you appropriately.
In this case, an end user would rightfully consider a stack trace to be a bug.
The features of the language of my choice makes a big difference in both debugability and robustness.
Most of the time, ease of debugging is a feature of the implementation, not the language. A C interpreter can easily tell you exactly which line of code caused the division by zero. A compiled C implementation can also note the instruction that caused the division by zero, and work back out to a line of source code.
There are different aspects of robustness. In the Java sense, you're probably referring the underlying platform protecting the system against errant programs. That's a great feature (which has a trade-off, of course), but Java programs are not inherently robust in the sense of handling user input correctly. Note that running a C program in a virtual machine, for example, has a similar effect.
Even that is a worthless statistic. Assuming that bad programs are written by bad programmers, the language that more bad programmers choose will appear the highest in your study as the buggiest language. Bad programmers choose the language du jour, thinking it will land them a cushy job.
You'll have to disprove the assumption to correctly blame the language.
Use better languages and crash less.
Try dividing by zero in your better language of choice.
This is not wholly accurate. TDMA is old, obvious, and proven technology, requiring nothing more complicated than a uniform source of timing, and is possibly less demanding on the handset hardware than CDMA. Telecommunications carriers tend to be conservative, because the upfront investments are astronomical.
Secondly, according to Qualcomm's own information, CDMA by 1995 offered only 10x improvement (over analog cellular) of the bandwidth utilization. By contrast, TDMA offers somewhere from 3x to 8x, so the case for ripping out all your expensive network hardware is not as compelling back then.
Today in Iraq, starting from scratch, the equation is obviously different. When GSM's time comes, however, it should be remembered as a reliable workhorse, not something that was always inferior to CDMA except for patents. GSM was the first mobile phone system that offered global roaming, a feature taken for granted today, but causing so many problems back then that several horribly expensive satellite based solutions were built.
SIMM card
Only one "M". It stands for "Subscriber Identity Module".
Possibly. Let's modify the analogy to suit the case a little better.
Let's say the table has a secret compartment, just like a large base of code like a Linux distribution is nearly impossible to inspect thoroughly. Let's say another person stole your bar of gold from your safe, and hid it in the table that you gave me.
What do you think now? Should you suffer the loss of that gold bar?
No, I'm really not. What I'd like to see is a more moderate form of capitalism, coming not from external pressures and regulation, but from internal philosophy. I'd like to see profit remain a goal, because economic growth really is important, and competition really does keep companies on their toes and makes things better.
The problem I have is that today, profits need to be maximized. $13B in profits is infinitely better than $12.5B. So much better that it's worth laying 30,000 people for. I'm talking about capitalists - most of them, at least - becoming more content with the returns on their investments.
I'm not only talking about the rich people. When we sign up for your 401(k) (US pre-tax retirement investment plan), and we only look at the ROI number, we're part of the problem.
Last, but not least, if the current system really bothers you that much, join a commune or "slack".
I don't want to do that. I enjoy working and making a good living. I just don't want to be pursuing the last dollar or cent I can get my hands on, ignoring everything I have to do to get it.
That isn't enough, and we're beginning to see hints of what's lacking in our culture.
Even in competitive Capitalism, the end goal is to maximize profit. Profit is not a bad thing, but the maximization of profit often brings about bad side effects. Companies dumping toxic waste into the river, lying executives, laying off many and overworking the rest, etc. Many of these are not only harmful to its employees and neighbors, but to the long term viability of the company itself. The need to look good in a quarterly report can drive an otherwise sane company to near suicidal stunts like shipping products before they are ready.
I'm not intelligent enough to have an alternative. I just would like to see a more moderate version where corporations can be content with some profit, and not have to squeeze every near-term dollar out of its employees, customers, and neighbors.
This is a beautiful sentence. It really is.
You imply that "disgusting" is worse than "immoral and unethical". Molds in your refrigerator are disgusting. Immoral and unethical should be much worse than fungal growths, which after all give us penicillin.
The problem is that it isn't. I know you don't mean it that way, but your sentence almost reads as if it's okay if you're immoral and unethical, as long as you're not disgusting. Which is exactly what's wrong with the world.
It's worse than that. All Monsanto really wants is profit, so "mercy" in this case can simply be purchased with dollars. (Yes, I'm being sarcastic.)
The problem is a global monoculture of food crops. As smart as Monsanto's scientists are, they cannot predict every possible attack. Planting an entire country full of identical crops, however, is just waiting for disaster, either from nature or from a terrorist biological attack. We're talking mass starvation and subsequent breakdown of entire societies, not just economic dependency.
Can Monsanto save us from such an attack?
Hmm?
Social skills are measured by how many human situations one can harmoniously fit into. For example, if you're well liked among geeks, jocks, and bikers, then you might have good social skills. If you're only accepted among geeks who play a particular board game, then you might not have very good social skills. I don't understand how or why you are separating the two.
(I don't know who David Arthur is, and I'm not talking about him.)
This value comes at a price. You helped create a monoculture of operating systems, where interoperability is possible essentially only when Microsoft was late to the party, where a single virus outbreak may take down most of the world's connected desktops, and where one company decides where you want to go today.
I like Apple, but I wouldn't want to see Apple with 95% of the market either. What I want is diversity, where several competing platforms capture various niches, none able to dominate the others.
Funny you should mention value for the dollar. You do realize that Microsoft can probably sell Windows at $10 a copy and still make money, right?
Did you actually read my post?
The OS is not the problem. It can handle many more windows than any person can. It's the 2-D desktop metaphor that's limiting us today.
What good is it for anyone who actually closes windows they aren't using?
Why should you have to close it? You're so conditioned to the way you work that you can't "zoom out" and consider that there may be other ways to get things done.
You may know of people who appear messy, because they have stacks of papers all over their desk. However, some of these people can easily find what they need, despite the apparent mess. These people are able to remember chronologically and spatially where their documents are. A 3-D desktop like I mentioned may actually find a document faster than the traditional nested folders option.
Seriously, I've never known anyone who actually needed more than 8-12 windows at a time and those are power users
Has it ever occurred to you that maybe it's not that they couldn't use more open windows so much as they can't handle so many open ones, under the current metaphor of the 2-D desktop?
If you observe a user of Apple ][ in 1982 or so, you'll notice that even power users only used one task. If you concluded that even power users only need one task, you'd be wrong. How about circa Windows 3.1? People had multiple windows, but you couldn't really have all that many open, because screen resolutions were poor.
This again is a wasted resource.
Try to be open minded. Have you ever even used a 3-D desktop like I described? Besides, if you paid attention, you'd realize that almost all of the work is done by my very idle 3-D GPU.
Let me give you an example.
First, imagine your current desktop as having depth. Each window is a different distance from you, and windows that are "nearer" to you can obscure windows that are "farther". If you are constrained to looking at your stack of windows from one direction (the front), then visually that's what you have today.
One limitation of this is that you cannot really have too many windows. Windows in the "back" can be hard to get to, and bringing them "in front" can obscure other things you want. In other words, we have a space management problem, and the granularity is the window.
Now, imagine if you rotated that view 90 degrees to the left or right, and assume that your windows are one pixel "thick". You'd expect to see a number of vertical lines, each representing a window. This view is pretty useless, because you'll have a hard time figuring out which window is which. However, it does sudden show all of your windows.
Where does 3-D come in? It lets you rotate your desktop at any angle between 0 (in front) and 90 degrees to the left or right. This allows you to take peeks behind the top windows, without actually bringing the rear windows forward. To improve the effect, "near" windows can become more transparent as the viewing angle increases, showing more of what's behind.
How do you control that? Very easily. If you have a multi-button mouse, you can hold down one special button and move the mouse in any direction to rotate the desktop in that direction. Let go of the mouse button, and the display snaps back to the "in front" view.
It's not going to change the world, obviously, but I think this may enable people to effectively use more windows than before.
I don't think that's accurate. Average Linux users don't want to build everything from source. They use binary distros.
Please read my post again, or find yourself an authoritative reference in C. In C, the order of evaluation is essentially undefined, except at sequence points, where all previous expressions and side effects are fully evaluated. Accessing and modifying an object separately between two sequence points is undefined behavior.
It has nothing to do with associativity, which only means anything if your C statement doesn't invoke undefined behavior.
However my compilers disagree with each other.
Not only that, your compiler may disagree with itself depending on whether optimizations are enabled or not. This is because you invoked undefined behavior, for which no particular result can be expected.
That's probably going too far. An EKG might show excitement, but AFAIK cannot distinguish between fear and other emotions such as anger.
In any case, if such an incident came to trial, the relevant evidence is whether the officer obeyed procedures, and whether a reasonable person should fear for his or her life. If the officer was unreasonably scared, he or she will still be guilty of misuse of force or whatever.
I see. I was confused by the way you phrased the statement, which made it sound like there were many cases of relying on compiler quirks without meaning to, which is just sloppy. Bugs are of course a fact of life, but they should be few and far in between for a mature product like Linux.
You're not alone. It doesn't even have to be a real tax preparation software or website. How about just an Excel spreadsheet template that I can fill in, and email to them? Security minded? How about a secure website I can upload the spreadsheet to? These are things that will take literally a few hours to do.
If I don't feel like spending for tax software, why should I have to do all that stupid arithmetic when I have three computers in the house?
Now that you understand the problem, I strongly suggest you acquire an authoritative reference for C or C++, whichever you are using. If you can read the ISO standard, that's obviously the best resource. Electronic copies are available for about $20, I think.
What you did was rely on something the language never guaranteed. C defines a concept called a sequence point (mainly the ';' at the end of a statement, but there are other sequence points), at which point all previous expressions would have been fully evaluated. Between two sequence points, however, it guarantees nothing. So, this:
is undefined, because since '=' is not a sequence point, you don't know which value of 'i' will be used to get a[i]. In fact, as you've found out, it can differ between debug and release builds. On the other hand, this:is valid C code, because ';' is a sequence point, and 'i' is not both modified and accessed between two sequence points. C++ basically inherits all of this from C. Sequence points in C is a level of understanding that should give you chills thinking back at every line of code you've ever written.When I arrived at SAGEM, progammers wereeven releasing Debug versions of their programs, because they didn't want to spend time on finding why release mode was not working
That's just sloppy. A difference in behavior between debug and release builds can be an indicator of major bugs that are merely better hidden by the debug version. The bug may still surface when the program is subjected to real world loads, or some unexpected input. It's possible that a compiler bug causes the release build to be broken, and so you ship the debug build, but not investigating is plainly irresponsible.
It's possible to check at compile time. It's not so much that the compiler detects whether a parameter is null or not at compile time, but whether it can be. For example:
can trigger a warning or error, because malloc() does not return a "nonnull" pointer, and so passing p to do_work is dangerous. On the other hand, given the code:then the compiler can work out that the call is safe. This is how LCLint, for example, can do with itsReally? I would consider that to be terrible code. It's one thing to intentionally rely on compiler quirks, because sometimes you really don't have a choice. It's another entirely to not even know that your code relies on a particular version of the compiler. An unintended portability problem is a bug, produced by a programmer who doesn't know his or her language!
Absent proof of many portability bugs in Linux, I don't think your assertion can stand.