1) Extreme programming doesn't mean skipping
design, it means building only what you need.
You're still building that little bit with
the same attention to all facets of software
engineering.
The point being that when you don't know what
you'll eventually have to build, no amount of
intelligence, forethought, or design will solve
that problem. You build what you know you need,
and flow along with changing requirements.
2) Who's to say that the better overall choice
is to correct the so-called "negative traits".
There is some cost associated with doing so.
If they are important enough, they will get
fixed. Maybe (as is often the case) getting
something that mostly works makes the users
happier than something "properly design[ed]
from the start" yet six months later.
(Not to say that design slows down a project;
attention to design should and will speed up
work. But too much Capital-D Design up front
-- before the questions are really explored,
and before you have a working version to
pound on and gain understanding from -- will
end up a losing proposition in the end.)
The blessing and curse of software development
is that everything you are doing is necessarily
new in some way. If someone has done it before,
why would you be writing it again? That
combined with the push to solve the difficult
problems in software rather than hardware
(because software is *easy* to change!?) means
each project is an exploration.
And to the extent that the exploration is into
more and more unknown territory, you need the
steps of iterative and "agile" processes to
get yourself a good feedback loop into your
problem domain.
Otherwise you end up over time and over budget
(if it even works at all), because you had a
great design for the wrong problem.
It is true that the "apt" part of debian -- a modular packaging system with dependencies that are carefully expressed and automatically installed -- is a beautiful thing, and that other distros have similar tools.
However, even just looking at the practical (rather that philosophical) side, apt is not the best part of Debian.
The best part of Debian is a set of packaging conventions (the Debian Policy Manual), and a set of tools and a QA system to support that system, with the result that the software you use from Debian is consistently well-integrated, even though it is crafted by a distributed group of volunteers.
The social norms and continual build-up and exposition of best practices, expressed in part by the Debian Policy Manual, is really the best practical characteristic of Debian.
The freedom thing (and corresponding attention to software licensing) is nice, too.
A number of active debian developers are already advocating this approach, and other similar ones. You can read the "debian-devel" list archives to view some of the discussion.
The thread begins at: http://lists.debian.org/debian-vote/2004/debi an-vo te-200404/msg00074.html
Much of the discussion has migrated to debian-devel, but its web archives have not been updated yet. Check the debian-devel archives later for a thread of the same name.
A few disclaimers, from someone who reads debian-* lists regularly, but isn't part of the project...
(1) Much of what is proposed is about moving pieces of the OS from the "main" archive to the "non-free" archive; "main" is what you get on the Debian CDs, "non-free" is available via ftp. So it is probably less convenient to obtain, but not totally expunged from debian.
Of course, components that affect your initial installation are more sensitive to the method of distribution, but other projects are welcome to build mixed installer tools that combine the default debian installer with the non-free firmware.
(2) This was only announced about 24 hours ago. Things are still in a state of flux, so don't take the "all this is happening and sarge is now year(s) away" too literally.
(3) Don't read into the summary that this solely a personal decision by Anthony Towns, or that he is necessarily in favor of the proposed changes.
To help answer the grandparent's question: compile != matches API.
Can you write a test-compile program that checks whether the proper public/private/proctected access modifier keywords are set up right on each method? That the method was specified for 'short foo' but the implementor used 'int foo'? Or like Mithrandir said, that no additional methods have been added (such as an overloaded version)?
Basically, compile-compatability is not the same as using the precise APIs in the spec.
So to solve your stated problem of "I can't remember a bogus login/pass for NYT" you propose "remember this algorithm: if its the first of Saturday of a leap year, then... etc." Doesn't sound like its solving *your* problem, to me.
You can also just use the program dvipdfm, which does the right thing with eps files, and most other things. It is an easy way to make PDFs from TeX that people can actually read.
If the script just picks code files (as opposed to object and binary files), the space required will be miniscule.
You might think so... however, having administered a course doing something similar (saving versions of students' source) it grows faster than you think. Take 300 students x 30 files each x saving every hour for a semester. It pushed the limits of the network-replicated storage the class was allocated (even taking unmodified files into account).
CVS by individual students in their own filespace is a much better option. Admins can set it all up for them just the same, and CVS in emacs is as easy as 'C-x v v'.
What the #@$!... I blocked "Ask Slashdot" from my preferences for a reason. I hate reading stories with inane questions. Y'all gonna make me block all of Cliff's articles now, too?
This isn't a problem with Outlook, it's a problem with idiot users clicking on every damn thing they're emailed.
Furthermore, Outlook actually helps out the "idiot" users. I have all patches and security enhancements setup for my Outlook client, and when I got copies of this trojan in my email, Outlook would not let me open the executable attachment. The problem is users doing silly things, and Outlook can be configured to be safe. An argument can be made about default configuration, but that's another matter. This isn't a stody about a hole in MS software; it's a problem with users and with badly maintained software.
The porn people do that because various browers (in the past, but they live forver) interpreted http://##/ as a local intranet machine, and thus gave it more trust, let it do more things within the broswer, automatically tried to logon with your creds, etc.
Dude, if the lights in an airport go out, they've got more to worry about than blind people finding their way around. They've got to worry about everyone else finding they way, too!!
My God. I thought I'd read Katz again after a break; give him a chance. But THIS! It's worse that the John Dvorak trolling that slashdot regularly links to. Maybe he just doesn't have anything real to write about, so a stir-the-flames MS troll will still keep him employed. Ugh.
On an interesting sidenote: it seems that the film revenues for "R rated" films have gone down ever since the movie industry started "enforcing" their ratings.
Now, let me get this straight... they block people from seeing to a movie, offering it to fewer customers, and the amount of money they make on that movie goes down? Shocking!
Is anyone else disturbed that Taco left out the apostrophe in "President's"?
Re:How many points for telling you the odds?
on
Bioinformatics
·
· Score: 2
Your analysis is correct, insofar as you require the DeCSS bases to appear, unbroken, as a string within the genome.
However, perhaps we don't have to require the string to be unbroken. For example, would the pattern "use 100 bases, skip 10, use 100 bases, skip 10..." be an acceptable algorithm for finding DeCSS in the genome? If so, the probability increases combinatorally, so perhaps isn't as unlikely as you think.
As the string length gets small enough to be feasable (log4 3*10^9) ~ 16 bases, you have to start using inclusion-exclusion instead of just multiplying by M-N, which I don't feel particularly compelled to do right now.
My point is just that there are more feasible encodings than a bits-to-bases unbroken string, so the chances are higher when you allow those cases.
Slashdot Mirror
1) Extreme programming doesn't mean skipping design, it means building only what you need. You're still building that little bit with the same attention to all facets of software engineering.
The point being that when you don't know what you'll eventually have to build, no amount of intelligence, forethought, or design will solve that problem. You build what you know you need, and flow along with changing requirements.
2) Who's to say that the better overall choice is to correct the so-called "negative traits". There is some cost associated with doing so. If they are important enough, they will get fixed. Maybe (as is often the case) getting something that mostly works makes the users happier than something "properly design[ed] from the start" yet six months later.
(Not to say that design slows down a project; attention to design should and will speed up work. But too much Capital-D Design up front -- before the questions are really explored, and before you have a working version to pound on and gain understanding from -- will end up a losing proposition in the end.)
The blessing and curse of software development is that everything you are doing is necessarily new in some way. If someone has done it before, why would you be writing it again? That combined with the push to solve the difficult problems in software rather than hardware (because software is *easy* to change!?) means each project is an exploration.
And to the extent that the exploration is into more and more unknown territory, you need the steps of iterative and "agile" processes to get yourself a good feedback loop into your problem domain.
Otherwise you end up over time and over budget (if it even works at all), because you had a great design for the wrong problem.
It is true that the "apt" part of debian -- a modular packaging system with dependencies that are carefully expressed and automatically installed -- is a beautiful thing, and that other distros have similar tools.
However, even just looking at the practical (rather that philosophical) side, apt is not the best part of Debian.
The best part of Debian is a set of packaging conventions (the Debian Policy Manual), and a set of tools and a QA system to support that system, with the result that the software you use from Debian is consistently well-integrated, even though it is crafted by a distributed group of volunteers.
The social norms and continual build-up and exposition of best practices, expressed in part by the Debian Policy Manual, is really the best practical characteristic of Debian.
The freedom thing (and corresponding attention to software licensing) is nice, too.
A number of active debian developers are already advocating this approach, and other similar ones. You can read the "debian-devel" list archives to view some of the discussion.
i an-vo te-200404/msg00074.html
The thread begins at:
http://lists.debian.org/debian-vote/2004/deb
Much of the discussion has migrated to debian-devel, but its web archives have not been updated yet. Check the debian-devel archives later for a thread of the same name.
A few disclaimers, from someone who reads debian-* lists regularly, but isn't part of the project...
(1) Much of what is proposed is about moving pieces of the OS from the "main" archive to the "non-free" archive; "main" is what you get on the Debian CDs, "non-free" is available via ftp. So it is probably less convenient to obtain, but not totally expunged from debian.
Of course, components that affect your initial installation are more sensitive to the method of distribution, but other projects are welcome to build mixed installer tools that combine the default debian installer with the non-free firmware.
(2) This was only announced about 24 hours ago. Things are still in a state of flux, so don't take the "all this is happening and sarge is now year(s) away" too literally.
(3) Don't read into the summary that this solely a personal decision by Anthony Towns, or that he is necessarily in favor of the proposed changes.
See http://www.debian.org/devel/constitution, in particular sections #4 and A.
To help answer the grandparent's question: compile != matches API.
Can you write a test-compile program that checks whether the proper public/private/proctected access modifier keywords are set up right on each method? That the method was specified for 'short foo' but the implementor used 'int foo'? Or like Mithrandir said, that no additional methods have been added (such as an overloaded version)?
Basically, compile-compatability is not the same as using the precise APIs in the spec.
=^P
So to solve your stated problem of "I can't remember a bogus login/pass for NYT" you propose "remember this algorithm: if its the first of Saturday of a leap year, then ... etc." Doesn't sound like its solving *your* problem, to me.
You can also just use the program dvipdfm, which does the right thing with eps files, and most other things. It is an easy way to make PDFs from TeX that people can actually read.
CVS by individual students in their own filespace is a much better option. Admins can set it all up for them just the same, and CVS in emacs is as easy as 'C-x v v'.
Wow, I didn't know they could make GPS *transmitters* that small!
What the #@$!... I blocked "Ask Slashdot" from my preferences for a reason. I hate reading stories with inane questions. Y'all gonna make me block all of Cliff's articles now, too?
Also note that Kuro5hin has talked about this issue, too.
The porn people do that because various browers (in the past, but they live forver) interpreted http://##/ as a local intranet machine, and thus gave it more trust, let it do more things within the broswer, automatically tried to logon with your creds, etc.
Dude, if the lights in an airport go out, they've got more to worry about than blind people finding their way around. They've got to worry about everyone else finding they way, too!!
Your point is taken. From what I read on the Apache post, it seems that it's only Apache for Win32, which may explain why it wasn't front paged?
My God. I thought I'd read Katz again after a break; give him a chance. But THIS! It's worse that the John Dvorak trolling that slashdot regularly links to. Maybe he just doesn't have anything real to write about, so a stir-the-flames MS troll will still keep him employed. Ugh.
You can read two pages of responses to the interview, too!
Is anyone else disturbed that Taco left out the apostrophe in "President's"?
However, perhaps we don't have to require the string to be unbroken. For example, would the pattern "use 100 bases, skip 10, use 100 bases, skip 10..." be an acceptable algorithm for finding DeCSS in the genome? If so, the probability increases combinatorally, so perhaps isn't as unlikely as you think.
As the string length gets small enough to be feasable (log4 3*10^9) ~ 16 bases, you have to start using inclusion-exclusion instead of just multiplying by M-N, which I don't feel particularly compelled to do right now.
My point is just that there are more feasible encodings than a bits-to-bases unbroken string, so the chances are higher when you allow those cases.
Did you even read the article? It specifically said "the journey from bottom to top taking less than two minutes".