> I am downright embarrassed by the quality of my code.
Good. You recognize you have a problem, thus you are already getting better.
> It is buggy, slow, fragile, and a nightmare to maintain.
Instead, put your effort into maintainable, correct, and fast- enough code, in this order of priority.
> Do you feel the same way?
Only in part. As I get better, I see the problems with my old behavior, and I try to correct it.
> If so, then what is holding you back from realizing your > full potential?
I do not think there is a full potential, I think there is always some room for improvement, with diminishing returns probably.
> More importantly, what if anything are you planning to do > about it?
I try to always improve myself. Always try to produce the best I can possibly do, compatibly with deadlines and such. In no way I allow myself shortcuts for short term gain, which I could then regret later when I have to maintain the thing.
> [...] > Sadly the one constant in my career is that I am assigned > to projects that drift, seemingly aimlessly, from inception > to a point where the client runs out of funding.
Try to implement those project well. Maybe they'll fail anyway (management mistakes), but you can find your satisfaction in that you have done a good job. Probably nobody cares, but you should. It is what makes coding interesting to me: caring about the codebase, and improving it (and thus myself).
> Have any developers here successfully lobbied their company > to stop or cut back on 'cowboy coding' and adopt best > practices? Has anyone convinced their superiors that the > customer isn't always right and saying no once in awhile is > the best course of action?
Yes. "Best practices" is a very relative(!)term, but I get what you mean. I try to convince the people around me (especially above me) to avoid half-baked solutions in favor of good maintainable ones, or at least to avoid panic and think things through before acting. It is not always possible to avoid customer-driven development completely, but you can always make your case, especially if you do not fear to work more to implement the good stuff.
Btw, if any of you is contributing to any distribution, please stop distributing systems without a compiler. It should be available by default in all distributions.
Not having a compiler does not make the system more user-friendly.
It only makes it more difficult for users to start experimenting with their system.
You didn't get it did you? That's only the encoding. That's just telling you how to obtain the bytes back.
The problem is _meaning_. If I define a binary blob in my document, and it is not standardized how I should interpret the thing [ex: interpret this as an XY object in Word97] knowing the bytes gets you nowhere.
Microsoft relies exactly on this confusion to try to pass their format as "open". Don't be fooled.
Sorry, the idea is as dumb as the patents it tries to provide prior art for.
If it catches on, it might bring more consenus to the whole idea of software patents, by filtering out the "bad ones", that are easy to defeat in court anyway, suggesting that there is such a thing as a "good software patent". Which is not the case.
And it does not do anything about the far more dangerous complement of the set.
Software patents must be abolished, in whole, in all legislations.
> Actually writing code can easily be a generic position, > easily swappable
This is what most companies get wrong. Coders are not easily swappable, no matter how much policy you try to set up: the differences in skill have a tremendous impact on the quality of the code, and if a more talented supervisor must always veto/fix the code of its underlings, it is a waste of time for everyone involved.
Only good coders should work on the code base in any position.
Those who also show management skills should get burdened by the additional task of actually managing people and distributing work, and they will slowly code less and less, while the good coders which do not show management skills should just code on.
The decision to raise the price from $100 to $175 is a mistake in PR. They should have never made the price public if they were not sure about it, and just release it as the $200 OLPC when they were. By making it run proprietary operating systems, the project also fails to deliver the freedom it initially seemed to care about.
To sum it up, there are no complete alternatives for SF Compile Farm at the moment, and it will be missed a lot.
The suggested alternatives can partially alleviate the problem: http://www.testdrive.hp.com/ [FreeBSD, HP-UX, HP OpenVMS, HP Tru64 Unix, Mandriva, Debian, RedHat]
It is very similar to Ubuntu GNU/Linux, but guess what? No Linux there. It is Nexenta GNU/Solaris. As I see it, the name most suitable for the 'masses' is the name of the distribution.
> the problem is that if you make a damn smart program for flux, > after a couple of months different implementations of the same smart program will appear for: > - KDE/Qt > - GNOME (sponsored by Novell and with nice artwork, running on Mono) >...
-1: ignorant catting/dev/random. A program running on fluxbox would run unchanged under everything else, since fluxbox is not a desktop, therefore does not require bloated desktop-specific libraries, and there is no fluxbox-only software.
If you now feel you were comparing apples with oranges, you're on the right track.
A counter-petition basing on those arguments has no sense. This is not about whether it is technically possible to play wmv on our system. What they assert in their web site (and we, or at least I, see as wrong) is (paraphrased):
"since we produced the content in WMV format, and we believe that it is not legal to play WMV on your system, support for your system is impossible."
MAIL TO: streaming dothelpline at consilium europa eu
I'd like to suggest a fix for your FAQ page:
> The live streaming media service of the Council of the European Union can be viewed on > Microsoft Windows and Macintosh platforms. We cannot support Linux in a legal way. So > the answer is: No support for Linux.
I would reword the second-last sentence like this:
"We are too ignorant or too lazy to support GNU/Linux."
Qunu people should rethink the search semantics on the main page. Currently it does an OR of all terms, resulting in bad matches (people who sure are not able to help), for users trying to specialize the search.
> The GPL needs to be fixed. The zealotry needs to be put aside and people need to realize > that internal corporate use of software should trump so-called "freedom", so long as the > modified versions of the software are not distributed outside an organization/corporation > and its partners. The GPL needs to make it clear that it does not ever restrict users of > software, only public distribution thereof. Otherwise, these problems will keep popping up > (and getting worse).
Sorry to point it out, but even with your very low ID you have not the faintest idea about what the GPL is.
I have good news for you: you can use the GPL software internally as much as you want. If you do not redistribute the code, you have nothing to worry about.
> I am downright embarrassed by the quality of my code.
Good. You recognize you have a problem, thus you are already
getting better.
> It is buggy, slow, fragile, and a nightmare to maintain.
Instead, put your effort into maintainable, correct, and fast-
enough code, in this order of priority.
> Do you feel the same way?
Only in part. As I get better, I see the problems with my old
behavior, and I try to correct it.
> If so, then what is holding you back from realizing your
> full potential?
I do not think there is a full potential, I think there is
always some room for improvement, with diminishing returns
probably.
> More importantly, what if anything are you planning to do
> about it?
I try to always improve myself. Always try to produce the best
I can possibly do, compatibly with deadlines and such.
In no way I allow myself shortcuts for short term gain, which
I could then regret later when I have to maintain the thing.
> [...]
> Sadly the one constant in my career is that I am assigned
> to projects that drift, seemingly aimlessly, from inception
> to a point where the client runs out of funding.
Try to implement those project well. Maybe they'll fail anyway
(management mistakes), but you can find your satisfaction in
that you have done a good job. Probably nobody cares, but you
should. It is what makes coding interesting to me: caring
about the codebase, and improving it (and thus myself).
> Have any developers here successfully lobbied their company
> to stop or cut back on 'cowboy coding' and adopt best
> practices? Has anyone convinced their superiors that the
> customer isn't always right and saying no once in awhile is
> the best course of action?
Yes. "Best practices" is a very relative(!)term, but I get
what you mean. I try to convince the people around me
(especially above me) to avoid half-baked solutions in favor
of good maintainable ones, or at least to avoid panic and
think things through before acting. It is not always possible
to avoid customer-driven development completely, but you can
always make your case, especially if you do not fear to work
more to implement the good stuff.
They are different things, for different purposes.
"The Eee PC is not a competitor to the OLPC XO-1, another inexpensive laptop computer..."
See http://en.wikipedia.org/wiki/ASUS_Eee_PC
At least Ubuntu.
Btw, if any of you is contributing to any distribution,
please stop distributing systems without a compiler.
It should be available by default in all distributions.
Not having a compiler does not make the system more user-friendly.
It only makes it more difficult for users to start experimenting
with their system.
reminds me of Paranoia. Great game.
http://en.wikipedia.org/wiki/Paranoia_(role-playing_game)
You didn't get it did you?
That's only the encoding.
That's just telling you how to obtain the bytes back.
The problem is _meaning_. If I define a binary blob in my document,
and it is not standardized how I should interpret the thing
[ex: interpret this as an XY object in Word97]
knowing the bytes gets you nowhere.
Microsoft relies exactly on this confusion to try to
pass their format as "open". Don't be fooled.
<DATA xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="bin.base64">A ABWJAAMAAAAMDM0MC03NTAuZG9j7FxdjBtZVq5k8oPJeH/Y
S SSQsO5Gi7Zb2/HYVf5NVosc98+0End7XO4EtLNC1eXrdk3KVUV VuTs9gJgHdp9XQhoJnmYfWBjgB 9WAkEK5hdYMI596f+7Ot08oylSrXLdb577rnnnHvuuefmb5599 h+/f 37y/PlzfPTxa5r2Q7h+BNd/w/U/cP0vu A6uatozuL4GDTyH630A+k+4Fj+maX8F10FJ034Xrrd/HJ7D9as 3NO1f4fo3P PwvtwPf//z9rP93/rO1qblGBEPv6Jv0hGlo/V8 ev3t06+iWtvQpXbml/fU/XNfav6yx6+PfeI09P7uUf09+ff780 8kz1d/y47J/PyNa+ wQe/ejdy9r3b6TvV9++pv0cPP/308van4OG/f6vXdb+v s7pi/ef/cZl7btvXtY+/ydXtCsfgpU8uqpdGWraRw+uafjG7z3 gNnSR+xfg/g3zmkaA8NtHh xvrJ3+Z68PxPtbn7EvxflK/snP/j97+H+veE17VaGbukO+D8Q 9 nWQZxX4AIeR8POqn3/+Y44v+/MvE urTB29fTvTup3/7qvY9uP8Z0GWbRpy//AC8JMi1pnH9w88z8d7 fPuLfl qRrVRI4/a1Wa1Rjb0Wq1+p65vlsfUnnmO
d luck.
UEsDBBQAAAAIACBxKyxk+mOemWUK
AQRCwAtaCfHCQxBvCAnBSq
9Yc/9U9a4fMV7TXtk+cl7Vrm2c/AdemK+PIZTXsN/r4O
XJ/A9RwuDd6fwvUD
uLSypj2A65twvfMpTfsPuH7l09AmXL8EfP0Qrv
7RtXtE9px+
xXv2b/x8ecV9O4Pwvnh+a3Z56f4+3D+A
FJ5P
17QtEN0zeP6TV7Wlj+z35rdX/K
OJUMzpcLuB89yPqWlP5lP7I/H2X6s3s9xfP/4Kr2Xbg3/uiq
oC+vw/2bv/5fn//Wb37n
r/7OVe0Ll9Lvsn3ZT6m/8l4cz+L9svZ38K+xNxySsU
</DATA>
Goo
Sorry, the idea is as dumb as the patents
it tries to provide prior art for.
If it catches on, it might bring more consenus to the whole idea of
software patents, by filtering out the "bad ones", that are easy
to defeat in court anyway, suggesting that there is such a thing
as a "good software patent". Which is not the case.
And it does not do anything about the far more dangerous complement
of the set.
Software patents must be abolished, in whole, in all legislations.
> Actually writing code can easily be a generic position,
> easily swappable
This is what most companies get wrong.
Coders are not easily swappable, no matter how much policy
you try to set up: the differences in skill have a
tremendous impact on the quality of the code, and if a
more talented supervisor must always veto/fix the code of its
underlings, it is a waste of time for everyone involved.
Only good coders should work on the code base in any position.
Those who also show management skills should get burdened by
the additional task of actually managing people and
distributing work, and they will slowly code less and less,
while the good coders which do not show management skills
should just code on.
Prior art won't solve the software patent problem
(by Richard Stallman)
The article has been written a year ago:
http://www.linux.com/articles/57167
fa ce ad ec ad e0 fd ec af c0 ff ee 4b ad co de
The decision to raise the price from $100 to $175 is a mistake in PR.
They should have never made the price public if they were not sure about it,
and just release it as the $200 OLPC when they were.
By making it run proprietary operating systems, the project also fails to
deliver the freedom it initially seemed to care about.
To sum it up, there are no complete alternatives for SF Compile Farm
at the moment, and it will be missed a lot.
The suggested alternatives can partially alleviate the problem:
http://www.testdrive.hp.com/
[FreeBSD, HP-UX, HP OpenVMS, HP Tru64 Unix,
Mandriva, Debian, RedHat]
http://www.blastwave.org/ [Solaris]
But a lot of stuff is left out (at least NetBSD, OpenBSD, Darwin,
Linux on POWER, AIX).
Please prove me wrong and provide links for alternatives to the CF for those
systems.
> You know one of the easiest ways to make life simpler
> for people new to GNU/Linux?
> Just calling it fucking *Linux* rather than being pedantic.
You say pedantic, I say correct.
Most Free operating systems are different in that they are less monolithic,
and more a sum of parts.
What will you say the Nexenta distro is/will be, for example?
http://www.gnusolaris.org/
It is very similar to Ubuntu GNU/Linux, but guess what? No Linux there.
It is Nexenta GNU/Solaris.
As I see it, the name most suitable for the 'masses' is the name of the distribution.
> the problem is that if you make a damn smart program for flux, ...
/dev/random.
> after a couple of months different implementations of the same smart program will appear for:
> - KDE/Qt
> - GNOME (sponsored by Novell and with nice artwork, running on Mono)
>
-1: ignorant catting
A program running on fluxbox would run unchanged under everything else,
since fluxbox is not a desktop, therefore does not require bloated
desktop-specific libraries, and there is no fluxbox-only software.
If you now feel you were comparing apples with oranges, you're on the right track.
who is the poor soul who modded this flamebait?
It is the single most insightful comment here.
The last episode of the Linux Tech Show was just about this,
and I found it very informative.
Just skip the first few minutes of the hosts struggling with their own machinery, as always.
http://feeds.feedburner.com/~r/TheLinuxLinkTechSh
A counter-petition basing on those arguments has no sense.
This is not about whether it is technically possible to play wmv on our system.
What they assert in their web site (and we, or at least I, see as wrong) is (paraphrased):
"since we produced the content in WMV format, and we believe that it is not legal to play
WMV on your system, support for your system is impossible."
See the problem?
Happy new year.
MAIL TO: streaming dothelpline at consilium europa eu
I'd like to suggest a fix for your FAQ page:
> The live streaming media service of the Council of the European Union can be viewed on
> Microsoft Windows and Macintosh platforms. We cannot support Linux in a legal way. So
> the answer is: No support for Linux.
I would reword the second-last sentence like this:
"We are too ignorant or too lazy to support GNU/Linux."
The rest seems fine.
Thanks,
--signed--
yes. I choose, therefore I am.
Is there a tarball for it yet?
I could not find any.
Qunu people should rethink the search semantics on the main page.
Currently it does an OR of all terms,
resulting in bad matches (people who sure are not able to help),
for users trying to specialize the search.
> Jobs not recruiters..
Exactly. I think there is not much more that can be added; next one..
Same here.
At this point I am not only worried because nwn 2 does not
support gnu/linux, I am worried because maybe we won't see nwn 2 _at all_.
> While programming using SDL requires knowledge of C and access to a C compiler, using
> SDL_perl does not.
Instead, using SDL_perl requires knowledge of Perl and access to a Perl interpreter.
> The GPL needs to be fixed. The zealotry needs to be put aside and people need to realize
> that internal corporate use of software should trump so-called "freedom", so long as the
> modified versions of the software are not distributed outside an organization/corporation
> and its partners. The GPL needs to make it clear that it does not ever restrict users of
> software, only public distribution thereof. Otherwise, these problems will keep popping up
> (and getting worse).
Sorry to point it out, but even with your very low ID you have not the faintest idea about what the GPL is.
I have good news for you: you can use the GPL software internally as much as you want.
If you do not redistribute the code, you have nothing to worry about.