> Taking some time (a few hours) to pick a nice sans-serif font (think Arial) > for headlines and a complementary serif (think Times) for body text, can > very quickly improve any project.
Georgia and Verdana, from corefonts.sourceforge.net, are the ones I use almost exclusively when I just want a "regular" Serif or Sans font (respectively). The serifs on Georgia are IMO nicer than on Times New Roman. The only thing is, Verdana runs large, so if you're matching it up with almost any other font, you'll want Verdana at a slightly smaller point size than the other. But this is a really nice pair of fonts and goes great together.
Occasionally I also use the Bitstream Vera family.
I'm still looking for a nice freely-available script or brushscript font.
> Sometimes I spend a great deal of time getting things exactly even, or lined > up precisely when it doesn't matter, or getting the image dimensions in > pixels to be even multiples of 16.
Multiples of 16? I usually go for powers of 2:-)
Re:Wow, some people need computer counseling
on
Creative Data Loss
·
· Score: 1
> That has to be my favorite one in the article...I can't believe someone > actually tried to flush their laptop down the toilet. That's all I can say. > I can't believe, someone actually tried to flush their laptop down the toilet.
He probably wasn't operating under the belief that it would actually go down the toilet; he was just giving it a swirlie. Eighth-graders do this to one another's heads occasionally -- not because they believe they can flush the other student's head down the toilet, but because they believe putting his head in the toilet and flushing it will embarrass and humiliate him. It's clear to me that this guy was so frustrated with his laptop, he wanted to embarrass and humiliate it, so that the other laptops on the network would whisper behind its back.
> I've been able to get dead hard drives working again by throwing them on > the concrete.
No, no, you don't throw them *on* concrete; you throw them *in* concrete. That is, you embed the drive in a hunk of concrete, let it dry, and then throw it. The concrete converts the kenetic energy from your throw into an impact shock that can jar the drive and scare it into working again. The hard part is to get the concrete off the drive subsequently without dammaging the drive. Some people use a jackhammer for this step, but you have to be careful with that approach, because it's easy to break the drive.
It was originally shaped like a running shoe, but then somebody painted it pink and erected an SEP field, so now all anybody sees is a plain old sphere.
Hindustanis may have better *grammar* than hicks, but they're still a bit harder to understand, as a result of the accent (unless the hicks are from rural Virginia or Texas, in which case they're about equal).
The worst accents for English though are from people whose native language is tonal and doesn't make a big deal about consonants (e.g., Korean). The good thing about an accent from India is that they have the whole consonant thing down pat. In fact, it's the vowels they screw up mostly, and vowels are less critical to English than consonants. We even have a couple of domestic accents in the US that mangle the vowels pretty badly, such as Texas (err, Take-sus), where vowels are many long that would be short elsewhere.
> Though you do have to realize that sometimes congress has to appprove > money that is seen as an investment. Research for example can have high > cost now for later returns in savings.
It can. But very significant amounts of money are spent on things that really don't belong in the federal budget. (Granted, they might cut the wrong things. But, fundamentally, federal spending has been way out of hand for a long time.)
> You wouldn't accuse google of being horribly in the red because its spending > IPO dollars would you?
That's not debt. Debt is something you have to pay back. IPO money is revenue, money collected in return for something -- specifically, in return for shares in the ownership of the company.
I would *NOT* want to see the US Federal Goverment sell shares of ownership in itself at an IPO. That would be rather scary. But it's okay for Google to do that. In either case, it's not the same thing as debt.
> When the president and congress are from different parties, only bills > that get support from both sides get through.
Agreed. At one time, the salary of congresspersons was such that most of them worked other jobs for most of the year, and congress met for a few weeks each session. That has a certain appeal to it.
OTOH, while we're dreaming impossible dreams, what I really want is an ammendment so that if spending exceeds tax revenues, the congresspeople all forfeit their salaries and cannot run for reelection. That'd balance the budget in a hurry.
> Neither number takes into account the ~3% of ballots considered Spoiled. > If there's a manual recount, those Spoiled ballots will also be examined, > to try to determine voter intent. Yeah, you remember that phrase from 2000.
I remember it made a difference of about 500 votes, not 350 thousand.
> I do have to ask, will the recount be done upon the same voting machines?
One imagines that the phrase "hand recount" would indicate that the recount would be done by hand, not by machine. HTH.HAND.
I have nothing against doing the recount, but don't expect a very different outcome. If they want to do it to allay the fears of tampering, I have no problem with that. It will not, of course, shut up the conspiracy theorists.
> Well, can you graphically create Qt or Gtk+ dialogs?
Dunno. I admit, I haven't done any GUI programming. But it wouldn't surprise me if there were a module for that. (I happen to know that there's a WYSIWYG module for editing TeX documents, another thing I've never used, and which sounds implausible to people who don't grok the Emacs mindset, namely, "of course there's a module for that".)
> If so, why the hell is it an Emacs addon/plugin/thingy?
A module. Because, every high-level feature in Emacs is provided by a module. This is why autoloading is possible, which allows Emacs to consume quite small amounts of RAM in practice, despite gargantuan amounts of functionality being provided.
There may not be a module for graphically creating Qt or Gtk dialogs; I don't know -- if you really want to know, I suggest asking on gnu.emacs.help. One thing I can guarantee you: if you ask what the module for that is called, there's an answer you won't get: "Why would there be a module for that?" Because, it's something Emacs obviously *should* have a module for, and if it doesn't yet, there's probably someone out there somewhere trying to find enough time to code one up. So the response you'll get will either be, "Check out something-or-another-mode" or else "I don't know of anything like that being released yet; I think so-and-so was talking about it a while back, but I don't know how far he ever got."
> It could even tip the state (and thus the election) from Bush to Kerry.
Statistically, no, it couldn't. In fantasy fiction, it could, but in real life, with Bush leading by over a hundred thousand votes, it ain't gonna happen. For Gore in Florida in 2000, trailing by about a thousand votes, the recount was a bit of a longshot, although it was not beyond the realm of possibility that it could, against the odds, pan out -- but here, the margin is plainly way too large. (Kerry knew this, presumably, which is why he conceded.) Do all the recounts you want. Recount from now till inauguration day if you like -- but don't hold your breath waiting for any big announcements reversing the outcome. 130 thousand votes is close, yes, but it's not so razor thin that a recount has any realistic chance to alter the outcome. The counting process just isn't as sloppy as that. (Yes, there are ballots that weren't counted, but statistically they aren't going to deviate as wildly as all that from the rest. Even if 100% of them are valid and countable, and even if there are 250 thousand of them outstanding (the highest, most optimistic estimates for the Dems; the Blackwell figure of 175 thousand is probably much closer), and, indeed, even if Kerry gets a wildly unlikely 70% of those 250 thousand (in Ohio, where it is very unlikely for either party to top 60%), Bush would still have a comfortable enough margin of victory to be confident of the outcome of any recount (at least, any recount observed by representatives from both parties).)
I'm all for the hand recounts. They will verify what we already know.
(What we do not know is what would have happened if it hadn't rained all day statewide. There are always unknowns in life.)
> Maybe you don't know what you are doing. I have a clear idea of how > what I do in Dreamweaver will affect the source.
I know *exactly* how what I do in Emacs will affect the source:-)
> Even if it does do something I dont like it takes very little work in > the source to remedy it. It certainly doesn't mean that I have to redo > the whole thing from scratch.
Perhaps WYSIWYG editors have improved since I last looked at them, but every time I see a web page created in one... I see evidence to the contrary. Maybe you're one of a few rare people who can actually make them work properly? Dunno, but vanishingly close to 100% of the web pages created with them are such utter crap, they need to be rewritten from scratch just to get them to scale to a resolution other than the one the designer was using. If you can manage better, good for you.
> If it costs you time, don't use it.
I don't.
> For the rest of us who know what we are doing, we are going to keep using it.
I don't think it's reasonable to conclude that everyone who uses it knows what they're doing. I'm certain that's not so (as with most software).
> Remeber one thing: HTML is super easy, and doing it by hand does not make > you hardcore. I can "code" HTML in my sleep.
That was rather my point: HTML is so easy to do by hand, wanting a GUI tool for creating it is... just plain bizarre. A text editor with a handful of macros is much more efficient. Admittedly, what I use is not so much a handful of macros as almost a major mode that I've put together out of bits and pieces over the years, and that integrates with and piggybacks on cperl-mode, but you wouldn't have to have all of that to be more efficient than a WYSIWYG editor; half a dozen macros would do in a pinch, I would think.
There are even people who claim Notepad is a good HTML editor, but you will note that I don't go that far. Editing HTML in Notepad would be quite tedious, because of the lack of macro support; you'd have to type every character of both the opening and closing tags for each element, which would be rather more typing than is strictly necessary. If that's what you're comparing to, then I can see why you prefer FrontPage.
As far as being hardcore, I didn't intend to imply that, sorry for any confusion; indeed, computers aren't really even my strong subject (though they're not my weak subject either). But as you point out, HTML is a very long way from hardcore.
So, in other words, if you wanted to avoid the requirement to provide the source to anyone who asks for it, all you'd have to do is bundle it with all the copies of the binary you distribute. For example, if a hypothetical laptop developer made modifications to Linux to support some of their hardware so that they could distribute laptops with Linux preloaded, they could just throw the source for their custom kernels onto the hard drives (and, if applicable, the restore CDs) and would not then be required to maintain a public download of it, contribute it back to kernel.org, or any of that sort of thing. Anyone purchasing one of their laptops would be free to do so, but the company wouldn't have to trouble themselves.
> The ONLY ***only*** reason that BSD stuff can't usually become GPL stuff is > the fact that so many people own the copyrights on it that it would be > absolutely impossible to contact them all and ask for their (written) > permission to use the code involved
You were doing okay up to this point, but here you got confused. The BSD license actually gives you permission to use the work, provided you follow all the provisions of the license. As it turns out, relicensing under the GPL does not violate any of the provisions of the BSD license. (There was at one time an old version of the BSD license for which this was not true, but that was a long time ago and is of little relevance today.)
What you cannot do is go the other way, including or linking against GPLed code and releasing under the BSD license. The BSD license allows things that the GPL does not allow, so relicensing GPLed code under the BSD license does not follow all of the requirements of the GPL -- so you can't do it.
This is where the GPL gets its "viral" epithet: if you mix BSD and GPL stuff together, the result can be released under the GPL, but it cannot be released under the BSD license; to release under the BSD license, the GPL parts have to be replaced with BSD code, or code licensed in a way that is compatible with the BSD license.
> If these people molested a BSD project in the same way they've molested > ReactOS (not giving credit where credit is due, as per the BSD liscense) > they'd be in just as much shit.
Indeed, there was a fiasco not very long ago wherein someone released a "new" BSD distribution (I no longer recall the name of it) that was essentially one of the existing ones (I don't recall which; might've been NetBSD, but I'm not sure) with the copyright statements changed and the references to the previous distribution removed. They were not permitted to continue distributing this, because it violated the terms of the BSD license.
However, if they had followed the license by retaining the copyright statements and so on and so forth, they then would have been permitted under the terms of the license to distribute the resulting product.
As opposed to Emacs, which has had more than ten times the functionality of its nearest competitor for decades? Name a feature it lacks, that *any* other IDE has.
Granted, it also has the "learning curve" feature in a significant way. That could be greatly improved by a configuration that mass-rebinds all the keys to match what users of other software expect... but this would be a huge undertaking, because it would have to rebind the keys in every important major and minor mode.
> Control. If you want pixel-level control, you can have it. At a price. > And if you don't care about legacy browsers.
My usual standards for legacy browsers (basically, anything over two years old) is that the page be legible and usable. If the layout doesn't look quite as intended, I don't fret over it, as long as everything's there, doesn't overlap, and so on.
These are my same criteria for less than 24-bit color: it has to be legible (down to 16-color mode, and also 8-bit greyscale; I do not attempt to support 1-bit monochrome); it doesn't have to look great at the low end, though. And with image-loading turned off, again, I use the same criteria: it has to be legible and usable, but it doesn't have to look like it was intended to be viewed that way. And with scripts disabled -- it has to be possible to navigate the site, but if the user has to type things in by hand that the scripts would have automated, so be it. And so on.
This allows a site to be _enhanced_ by newer technology without _requiring_ it.
> Which is easier, dropping '15px' in code, refreshing a browser to see how > it looks, or dragging the side of a table (or div if you will) out a bit > to get the right sizing.
Your problem is, you're writing the code the same way the WYSIWYG editor would, which is to say the wrong way. 15px is wrong for a very significant percentage of the users viewing your page, because (gasp) they aren't all viewing it on your computer (with your resolution and window size and other settings).
Specifying things in pixels is just one of numerous glaring mistakes WYSIWYG editors invariably make that cause their output to need to be rewritten from scratch before it can be usefully deployed on the web. If you don't want to bother rewriting it, you end up telling your users, "Please view this page in this specific version of this specific browser on this specific version of this specific operating system with these specific color settings in your theme, with your font size set to this specific value and your resolution set to this specific size and your taskbar in this position and this size, and maximize your window, and make sure you have these fonts installed, and set your preferences to these specific values..." and then if the user sets the GUI to "Classic" instead of Luna, it throws everything off by three pixels and your whole layout is ruined.
Of course, no two of these websites have exactly the same requirements. The first couple of times users see these kinds of requirements, some of them attempt to comply (if they know how to change such things, which many don't), but after a dozen or so sites ask them to *yet again* tweak their settings, they get tired of it and just go find another site.
Yet, somehow, there are websites out there that manage to scale, so that they look okay at 640x480 and yet still look good at 1600x1200.
> Having said all that, I completely agree that something that would rival > Dreamweaver would be great to see in OSS. It isn't a tool for amatures to > avoid learning HTML. It is a tool designed for professionals to save time. > And Dreamweaver does a great job at it.
Except, it doesn't save time: it *costs* time, because as soon as you want to make a nontrivial change, you have to redo the whole thing from scratch.
> paragraph 1: learn to use html via text editor, it gives you better control > Thanks, I'm aware of that. I could also learn to play the violin so I don't > have to listen to the radio. Oh, that's right--it's not something that I > want to spend an hour a week on for the next year.
Huh? If you spent an hour a week learning HTML, you'd know HTML very well in a month. It takes about thirty minutes to learn enough HTML that you never want to use a WYSIWYG HTML editor again. At that point you'll still keep a reference handy (like the one at w3schools.com or the one at htmlhelp.com), but it's still faster and easier than fighting with a WYSIWYG editor.
Oh, and don't bother with HTML 4.0 at this point; just skip straight to XHTML. It's actually simpler and easier, if you don't have preconceptions in your head from a prior knowledge of older versions of HTML.
> could it please come with a good tutorial/wizard that helps the user think > through the issues?
People who use wizards don't think through issues. They click "Next" until it's all done. Conversely, people who think through issues don't like wizards, because they're grossly inefficient (in terms of the number of screens, number of clicks, and so on) for what they accomplish.
As far as database GUIs, I think they're great for *most* databases. *Most* of the world's databases consist of data that can readily be stored in a single table, with a relative handful of columns (no more than perhaps 20) and a single row for each record. Heck, fully *half* of the world's databases are essentially a list of names with attached addresses and phone numbers and stuff. You don't need a DBA for that, nor SQL, nor even a computer geek really. The database in MS Works 4.x is good enough. You can sort by any column with a single click, how convenient is that?
When you start needing multiple tables, or having multiple rows that logically belong together (e.g., some for people you have multiple addresses and phone numbers beyond there home/work ones that you have columns for), you start going beyond the boundaries of what the non-geek user can handle doing with a GUI, and at that point you want a relational database and a geek. If it's only a couple of records pushing your boundaries that way, you deal with it in a Notes column, no big deal, but when it starts being a significant number of records, or if you just plain need multiple tables, it's time to get a geek, someone with a mind trained to think in layers of abstraction and organize data in more than two dimensions -- and he's probably going to want a relational database.
Honestly, I don't think a wizard or anything like that can fundamentally change this. You might push back the edge a little, but not very far.
> real obfuscation comes from indecipherable variable names, unused variables,
No, these things are pretty trivial to deobfuscate. Like the whitespace, you do them, just for the added visual effect, but they only contribute a little to the overall difficulty of deciphering the code.
> complex algorithms that accomplish no more than simple iteration, etc.
Counterintuitive algorithms are good. Abuse of obscure language (or compiler) quirks can also be fruitful territory. Most of the best obfuscations that I've seen, however, center around obfuscating the code in entirely another language from the one the contest centers on, then writing an obfuscated interpreter for that language in the contest language. For example, for the Obfuscated Perl Competition, you might write the actual functional part of your code in obfuscated Postscript and integrate a PostScript interpreter written in the best/worst obfuscated Perl you can manage. For the IOCCC, you might write your entry in Threaded Intercal and then wrap it up in a Threaded Intercal interpreter that you write in the most obfuscated C you can manage.
I prefer, if the language in question allows it, to use variable names containing unicode characters that are similar in appearance, so that for example one variable might have the letter omicron where another has the Latin letter o, and one variable might have a capital rho where another has a Latin capital P. This will be possible for example in Perl6. Abuse of soft references that do mildly exotic things (e.g., call a closure) to determine the variable name can also be fun.
In Perl it's also possible, at least in theory, to just about completely avoid supplying any variable names, by abusing magic variables, such as $_ (in Perl5) or the current topic (in Perl6). However, this is only hard to read for people who don't think in Perl, so it needs to be combined with additional obfuscatory techniques, such as mimicry of other languages, extensive abuse of pack and unpack, nested self-modifying string evals, and so on and so forth.
Slashdot Mirror
> Taking some time (a few hours) to pick a nice sans-serif font (think Arial)
> for headlines and a complementary serif (think Times) for body text, can
> very quickly improve any project.
Georgia and Verdana, from corefonts.sourceforge.net, are the ones I use almost
exclusively when I just want a "regular" Serif or Sans font (respectively).
The serifs on Georgia are IMO nicer than on Times New Roman. The only thing
is, Verdana runs large, so if you're matching it up with almost any other
font, you'll want Verdana at a slightly smaller point size than the other.
But this is a really nice pair of fonts and goes great together.
Occasionally I also use the Bitstream Vera family.
I'm still looking for a nice freely-available script or brushscript font.
> Sometimes I spend a great deal of time getting things exactly even, or lined
:-)
> up precisely when it doesn't matter, or getting the image dimensions in
> pixels to be even multiples of 16.
Multiples of 16? I usually go for powers of 2
> That has to be my favorite one in the article...I can't believe someone
> actually tried to flush their laptop down the toilet. That's all I can say.
> I can't believe, someone actually tried to flush their laptop down the toilet.
He probably wasn't operating under the belief that it would actually go down
the toilet; he was just giving it a swirlie. Eighth-graders do this to one
another's heads occasionally -- not because they believe they can flush the
other student's head down the toilet, but because they believe putting his
head in the toilet and flushing it will embarrass and humiliate him. It's
clear to me that this guy was so frustrated with his laptop, he wanted to
embarrass and humiliate it, so that the other laptops on the network would
whisper behind its back.
> I've been able to get dead hard drives working again by throwing them on
> the concrete.
No, no, you don't throw them *on* concrete; you throw them *in* concrete. That
is, you embed the drive in a hunk of concrete, let it dry, and then throw it.
The concrete converts the kenetic energy from your throw into an impact shock
that can jar the drive and scare it into working again. The hard part is to
get the concrete off the drive subsequently without dammaging the drive. Some
people use a jackhammer for this step, but you have to be careful with that
approach, because it's easy to break the drive.
It was originally shaped like a running shoe, but then somebody painted it
pink and erected an SEP field, so now all anybody sees is a plain old sphere.
> Indians speak better English.
Hindustanis may have better *grammar* than hicks, but they're still a bit
harder to understand, as a result of the accent (unless the hicks are from
rural Virginia or Texas, in which case they're about equal).
The worst accents for English though are from people whose native language
is tonal and doesn't make a big deal about consonants (e.g., Korean). The
good thing about an accent from India is that they have the whole consonant
thing down pat. In fact, it's the vowels they screw up mostly, and vowels
are less critical to English than consonants. We even have a couple of
domestic accents in the US that mangle the vowels pretty badly, such as
Texas (err, Take-sus), where vowels are many long that would be short
elsewhere.
> Though you do have to realize that sometimes congress has to appprove
> money that is seen as an investment. Research for example can have high
> cost now for later returns in savings.
It can. But very significant amounts of money are spent on things that really
don't belong in the federal budget. (Granted, they might cut the wrong things.
But, fundamentally, federal spending has been way out of hand for a long time.)
> You wouldn't accuse google of being horribly in the red because its spending
> IPO dollars would you?
That's not debt. Debt is something you have to pay back. IPO money is
revenue, money collected in return for something -- specifically, in return
for shares in the ownership of the company.
I would *NOT* want to see the US Federal Goverment sell shares of ownership
in itself at an IPO. That would be rather scary. But it's okay for Google
to do that. In either case, it's not the same thing as debt.
> When the president and congress are from different parties, only bills
> that get support from both sides get through.
Agreed. At one time, the salary of congresspersons was such that most of
them worked other jobs for most of the year, and congress met for a few weeks
each session. That has a certain appeal to it.
OTOH, while we're dreaming impossible dreams, what I really want is an
ammendment so that if spending exceeds tax revenues, the congresspeople
all forfeit their salaries and cannot run for reelection. That'd balance
the budget in a hurry.
> I remember it made a difference of about 500 votes, not 350 thousand.
s/350/130/; Sorry, momentarily got confused. Still, that's quite beyond
the reach of even the scariest demon lawyers.
> Neither number takes into account the ~3% of ballots considered Spoiled.
> If there's a manual recount, those Spoiled ballots will also be examined,
> to try to determine voter intent. Yeah, you remember that phrase from 2000.
I remember it made a difference of about 500 votes, not 350 thousand.
> I do have to ask, will the recount be done upon the same voting machines?
One imagines that the phrase "hand recount" would indicate that the recount
would be done by hand, not by machine. HTH.HAND.
I have nothing against doing the recount, but don't expect a very different
outcome. If they want to do it to allay the fears of tampering, I have no
problem with that. It will not, of course, shut up the conspiracy theorists.
> Well, can you graphically create Qt or Gtk+ dialogs?
Dunno. I admit, I haven't done any GUI programming. But it wouldn't surprise
me if there were a module for that. (I happen to know that there's a WYSIWYG
module for editing TeX documents, another thing I've never used, and which
sounds implausible to people who don't grok the Emacs mindset, namely, "of
course there's a module for that".)
> If so, why the hell is it an Emacs addon/plugin/thingy?
A module. Because, every high-level feature in Emacs is provided by a module.
This is why autoloading is possible, which allows Emacs to consume quite small
amounts of RAM in practice, despite gargantuan amounts of functionality being
provided.
There may not be a module for graphically creating Qt or Gtk dialogs; I
don't know -- if you really want to know, I suggest asking on gnu.emacs.help.
One thing I can guarantee you: if you ask what the module for that is called,
there's an answer you won't get: "Why would there be a module for that?"
Because, it's something Emacs obviously *should* have a module for, and if
it doesn't yet, there's probably someone out there somewhere trying to find
enough time to code one up. So the response you'll get will either be,
"Check out something-or-another-mode" or else "I don't know of anything
like that being released yet; I think so-and-so was talking about it a while
back, but I don't know how far he ever got."
> It could even tip the state (and thus the election) from Bush to Kerry.
Statistically, no, it couldn't. In fantasy fiction, it could, but in real life,
with Bush leading by over a hundred thousand votes, it ain't gonna happen. For
Gore in Florida in 2000, trailing by about a thousand votes, the recount was a
bit of a longshot, although it was not beyond the realm of possibility that it
could, against the odds, pan out -- but here, the margin is plainly way too
large. (Kerry knew this, presumably, which is why he conceded.) Do all the
recounts you want. Recount from now till inauguration day if you like -- but
don't hold your breath waiting for any big announcements reversing the outcome.
130 thousand votes is close, yes, but it's not so razor thin that a recount
has any realistic chance to alter the outcome. The counting process just
isn't as sloppy as that. (Yes, there are ballots that weren't counted, but
statistically they aren't going to deviate as wildly as all that from the
rest. Even if 100% of them are valid and countable, and even if there are
250 thousand of them outstanding (the highest, most optimistic estimates for
the Dems; the Blackwell figure of 175 thousand is probably much closer), and,
indeed, even if Kerry gets a wildly unlikely 70% of those 250 thousand (in
Ohio, where it is very unlikely for either party to top 60%), Bush would
still have a comfortable enough margin of victory to be confident of the
outcome of any recount (at least, any recount observed by representatives
from both parties).)
I'm all for the hand recounts. They will verify what we already know.
(What we do not know is what would have happened if it hadn't rained all day
statewide. There are always unknowns in life.)
> Maybe you don't know what you are doing. I have a clear idea of how
:-)
> what I do in Dreamweaver will affect the source.
I know *exactly* how what I do in Emacs will affect the source
> Even if it does do something I dont like it takes very little work in
> the source to remedy it. It certainly doesn't mean that I have to redo
> the whole thing from scratch.
Perhaps WYSIWYG editors have improved since I last looked at them, but
every time I see a web page created in one... I see evidence to the
contrary. Maybe you're one of a few rare people who can actually make
them work properly? Dunno, but vanishingly close to 100% of the web
pages created with them are such utter crap, they need to be rewritten
from scratch just to get them to scale to a resolution other than the
one the designer was using. If you can manage better, good for you.
> If it costs you time, don't use it.
I don't.
> For the rest of us who know what we are doing, we are going to keep using it.
I don't think it's reasonable to conclude that everyone who uses it knows
what they're doing. I'm certain that's not so (as with most software).
> Remeber one thing: HTML is super easy, and doing it by hand does not make
> you hardcore. I can "code" HTML in my sleep.
That was rather my point: HTML is so easy to do by hand, wanting a GUI
tool for creating it is... just plain bizarre. A text editor with a
handful of macros is much more efficient. Admittedly, what I use is not
so much a handful of macros as almost a major mode that I've put together
out of bits and pieces over the years, and that integrates with and
piggybacks on cperl-mode, but you wouldn't have to have all of that to
be more efficient than a WYSIWYG editor; half a dozen macros would do in
a pinch, I would think.
There are even people who claim Notepad is a good HTML editor, but you
will note that I don't go that far. Editing HTML in Notepad would be
quite tedious, because of the lack of macro support; you'd have to type
every character of both the opening and closing tags for each element,
which would be rather more typing than is strictly necessary. If that's
what you're comparing to, then I can see why you prefer FrontPage.
As far as being hardcore, I didn't intend to imply that, sorry for any
confusion; indeed, computers aren't really even my strong subject (though
they're not my weak subject either). But as you point out, HTML is a very
long way from hardcore.
So, in other words, if you wanted to avoid the requirement to provide the
source to anyone who asks for it, all you'd have to do is bundle it with all
the copies of the binary you distribute. For example, if a hypothetical
laptop developer made modifications to Linux to support some of their
hardware so that they could distribute laptops with Linux preloaded, they
could just throw the source for their custom kernels onto the hard drives
(and, if applicable, the restore CDs) and would not then be required to
maintain a public download of it, contribute it back to kernel.org, or any
of that sort of thing. Anyone purchasing one of their laptops would be free
to do so, but the company wouldn't have to trouble themselves.
To me, that seems reasonable.
> The ONLY ***only*** reason that BSD stuff can't usually become GPL stuff is
> the fact that so many people own the copyrights on it that it would be
> absolutely impossible to contact them all and ask for their (written)
> permission to use the code involved
You were doing okay up to this point, but here you got confused. The BSD
license actually gives you permission to use the work, provided you follow
all the provisions of the license. As it turns out, relicensing under the
GPL does not violate any of the provisions of the BSD license. (There was
at one time an old version of the BSD license for which this was not true,
but that was a long time ago and is of little relevance today.)
What you cannot do is go the other way, including or linking against GPLed
code and releasing under the BSD license. The BSD license allows things that
the GPL does not allow, so relicensing GPLed code under the BSD license does
not follow all of the requirements of the GPL -- so you can't do it.
This is where the GPL gets its "viral" epithet: if you mix BSD and GPL
stuff together, the result can be released under the GPL, but it cannot
be released under the BSD license; to release under the BSD license, the
GPL parts have to be replaced with BSD code, or code licensed in a way
that is compatible with the BSD license.
> If these people molested a BSD project in the same way they've molested
> ReactOS (not giving credit where credit is due, as per the BSD liscense)
> they'd be in just as much shit.
Indeed, there was a fiasco not very long ago wherein someone released a
"new" BSD distribution (I no longer recall the name of it) that was
essentially one of the existing ones (I don't recall which; might've been
NetBSD, but I'm not sure) with the copyright statements changed and the
references to the previous distribution removed. They were not permitted
to continue distributing this, because it violated the terms of the BSD
license.
However, if they had followed the license by retaining the copyright
statements and so on and so forth, they then would have been permitted under
the terms of the license to distribute the resulting product.
> Good IDEs
As opposed to Emacs, which has had more than ten times the functionality of
its nearest competitor for decades? Name a feature it lacks, that *any*
other IDE has.
Granted, it also has the "learning curve" feature in a significant way.
That could be greatly improved by a configuration that mass-rebinds all
the keys to match what users of other software expect... but this would
be a huge undertaking, because it would have to rebind the keys in every
important major and minor mode.
But, the _functionality_ is there.
> Control. If you want pixel-level control, you can have it. At a price.
> And if you don't care about legacy browsers.
My usual standards for legacy browsers (basically, anything over two years old)
is that the page be legible and usable. If the layout doesn't look quite as
intended, I don't fret over it, as long as everything's there, doesn't overlap,
and so on.
These are my same criteria for less than 24-bit color: it has to be legible
(down to 16-color mode, and also 8-bit greyscale; I do not attempt to support
1-bit monochrome); it doesn't have to look great at the low end, though. And
with image-loading turned off, again, I use the same criteria: it has to be
legible and usable, but it doesn't have to look like it was intended to be
viewed that way. And with scripts disabled -- it has to be possible to
navigate the site, but if the user has to type things in by hand that the
scripts would have automated, so be it. And so on.
This allows a site to be _enhanced_ by newer technology without _requiring_ it.
> Which is easier, dropping '15px' in code, refreshing a browser to see how
> it looks, or dragging the side of a table (or div if you will) out a bit
> to get the right sizing.
Your problem is, you're writing the code the same way the WYSIWYG editor would,
which is to say the wrong way. 15px is wrong for a very significant percentage
of the users viewing your page, because (gasp) they aren't all viewing it on
your computer (with your resolution and window size and other settings).
Specifying things in pixels is just one of numerous glaring mistakes WYSIWYG
editors invariably make that cause their output to need to be rewritten from
scratch before it can be usefully deployed on the web. If you don't want to
bother rewriting it, you end up telling your users, "Please view this page in
this specific version of this specific browser on this specific version of
this specific operating system with these specific color settings in your
theme, with your font size set to this specific value and your resolution set
to this specific size and your taskbar in this position and this size, and
maximize your window, and make sure you have these fonts installed, and set
your preferences to these specific values..." and then if the user sets the
GUI to "Classic" instead of Luna, it throws everything off by three pixels
and your whole layout is ruined.
Of course, no two of these websites have exactly the same requirements. The
first couple of times users see these kinds of requirements, some of them
attempt to comply (if they know how to change such things, which many don't),
but after a dozen or so sites ask them to *yet again* tweak their settings,
they get tired of it and just go find another site.
Yet, somehow, there are websites out there that manage to scale, so that they
look okay at 640x480 and yet still look good at 1600x1200.
> Having said all that, I completely agree that something that would rival
> Dreamweaver would be great to see in OSS. It isn't a tool for amatures to
> avoid learning HTML. It is a tool designed for professionals to save time.
> And Dreamweaver does a great job at it.
Except, it doesn't save time: it *costs* time, because as soon as you want
to make a nontrivial change, you have to redo the whole thing from scratch.
> paragraph 1: learn to use html via text editor, it gives you better control
> Thanks, I'm aware of that. I could also learn to play the violin so I don't
> have to listen to the radio. Oh, that's right--it's not something that I
> want to spend an hour a week on for the next year.
Huh? If you spent an hour a week learning HTML, you'd know HTML very well
in a month. It takes about thirty minutes to learn enough HTML that you never
want to use a WYSIWYG HTML editor again. At that point you'll still keep a
reference handy (like the one at w3schools.com or the one at htmlhelp.com),
but it's still faster and easier than fighting with a WYSIWYG editor.
Oh, and don't bother with HTML 4.0 at this point; just skip straight to XHTML.
It's actually simpler and easier, if you don't have preconceptions in your
head from a prior knowledge of older versions of HTML.
> could it please come with a good tutorial/wizard that helps the user think
> through the issues?
People who use wizards don't think through issues. They click "Next" until
it's all done. Conversely, people who think through issues don't like wizards,
because they're grossly inefficient (in terms of the number of screens, number
of clicks, and so on) for what they accomplish.
As far as database GUIs, I think they're great for *most* databases. *Most*
of the world's databases consist of data that can readily be stored in a
single table, with a relative handful of columns (no more than perhaps 20)
and a single row for each record. Heck, fully *half* of the world's databases
are essentially a list of names with attached addresses and phone numbers and
stuff. You don't need a DBA for that, nor SQL, nor even a computer geek
really. The database in MS Works 4.x is good enough. You can sort by any
column with a single click, how convenient is that?
When you start needing multiple tables, or having multiple rows that logically
belong together (e.g., some for people you have multiple addresses and phone
numbers beyond there home/work ones that you have columns for), you start
going beyond the boundaries of what the non-geek user can handle doing with
a GUI, and at that point you want a relational database and a geek. If it's
only a couple of records pushing your boundaries that way, you deal with it
in a Notes column, no big deal, but when it starts being a significant number
of records, or if you just plain need multiple tables, it's time to get a
geek, someone with a mind trained to think in layers of abstraction and
organize data in more than two dimensions -- and he's probably going to want
a relational database.
Honestly, I don't think a wizard or anything like that can fundamentally
change this. You might push back the edge a little, but not very far.
Agree about whitespace, but...
> real obfuscation comes from indecipherable variable names, unused variables,
No, these things are pretty trivial to deobfuscate. Like the whitespace,
you do them, just for the added visual effect, but they only contribute a
little to the overall difficulty of deciphering the code.
> complex algorithms that accomplish no more than simple iteration, etc.
Counterintuitive algorithms are good. Abuse of obscure language (or compiler)
quirks can also be fruitful territory. Most of the best obfuscations that
I've seen, however, center around obfuscating the code in entirely another
language from the one the contest centers on, then writing an obfuscated
interpreter for that language in the contest language. For example, for the
Obfuscated Perl Competition, you might write the actual functional part of
your code in obfuscated Postscript and integrate a PostScript interpreter
written in the best/worst obfuscated Perl you can manage. For the IOCCC,
you might write your entry in Threaded Intercal and then wrap it up in a
Threaded Intercal interpreter that you write in the most obfuscated C you
can manage.
> Since C does not have namespace features, I did the next "best" thing:
> explicitly have the entire namespace in each global identifier.
Much of Emacs is written this way. (I'm talking about the parts written in
elisp, not the basic pieces written in C.)
I prefer, if the language in question allows it, to use variable names
containing unicode characters that are similar in appearance, so that for
example one variable might have the letter omicron where another has the
Latin letter o, and one variable might have a capital rho where another
has a Latin capital P. This will be possible for example in Perl6. Abuse
of soft references that do mildly exotic things (e.g., call a closure) to
determine the variable name can also be fun.
In Perl it's also possible, at least in theory, to just about completely
avoid supplying any variable names, by abusing magic variables, such as $_
(in Perl5) or the current topic (in Perl6). However, this is only hard to
read for people who don't think in Perl, so it needs to be combined with
additional obfuscatory techniques, such as mimicry of other languages,
extensive abuse of pack and unpack, nested self-modifying string evals,
and so on and so forth.