The UK and US governments seem to think that there is something wrong with sex -- especially the non-procreative varieties -- but prefer to deal with it by pretending it doesn't exist.
To be fair, I think you'd have a hard time arguing that's the case. These governments don't have anything wrong with sex per se -- people are free to talk about it all the time, for example, just as we're doing now, and there aren't too many restrictions on actually doing it. The problem is with certain manifestations of sex: in particular, with images of people actually engaging in it. And not all the arguments that sex is perfectly natural and healthy and people have been doing it for tens of thousands of years apply to that particular manifestation.
Not that I'm saying it's wrong, just that more general case isn't always relevant.
Which is exercising free will, then -- passively looking at every web site you come across (pun intended), or choosing which web sites you'd like to visit?
iTunes is an app. It's a good way to organise and play your music. You may or may not like it, but you can use it without going near the iTMS. (I do -- the latter isn't even available here...) You can use it to manage MP3 downloaded from Magnatune or anywhere else.
Sorry to go on about this, but this misunderstanding seems to be spreading...
While I agree with most of your points, I must take issue with:
If the repository is not public, then how is it open source?
Open source does not necessarily mean that everyone has access to the source. It means that everyone who has access to the binary also has access to the source.
That's a very different proposition, but it's enough to ensure code freedom. (For common values of 'freedom', anyway.) That's how companies can legally modify open-sourced software for their internal use without releasing it. For that matter, that's how I'm able to modify open-sourced software for my private use without releasing it!
Ideally, every app should have a simple, elegant, intuitive, and flexible interface. If it has, then skins shouldn't be needed or wanted. If it hasn't, then surely much of the effort that goes into creating skins, or hooks for them, would be better spent improving the app in the first place! That way everybody would benefit.
What if cars came without a body shell, and you either got hot/cold/wet/windy driving, or had to hunt around for one of umpteen different body shells, most of which clashed with the car interior, many of which didn't fit properly and got in the way of the instruments or doors, and all of which let in draughts?
On the one hand, plain 7-bit ASCII text is the single most compatible format; just about any platform and app can handle it in some way or other. And it's likely to last longer than almost any other format. So as Gutenberg says, it's the most accessible format and the most future-proof.
But on the other, it's very thin. It has no structure: nothing to separate chapters, scenes, volumes, &c. It has no metadata: nothing to identify authors, translators, editions, dates, even titles, in a machine-readable manner. And it has no way to represent accented characters, directional quotes, and other characters that would greatly improve the typography.
The compelling argument for me, though, is that although you could automatically convert from a standardised rich format to plain text, it's impossible to convert the other way around without lots of manual work. If Gutenberg had chosen a rich format, even a very simple one, to start with, then all the benefits of plain text would come with that almost for free -- a simple open-sourced program would let people convert from the one to the other, and they could even provide both versions of texts on their web site.
FWIW, for my own reading I keep files in plain text but formatted in a particular manner: in Windows Latin-1, with accents and typography; with Palm-style bookmarks; and with conventions for chapter/scene/volume breaks, bold/italics, and metadata. It's a pain getting them there, but means they're ideal for reading on my palmtop, and also capable of being up-converted if the need arises.
Re: Writing is bad enough, testing is worse
on
Exploiting Software
·
· Score: 1
Having safe underlying library calls is nice, but it also introduces the possibility that actual errors will go unnoticed for a longer period of time.
Isn't the solution to have libraries that are safe, spotting and handling many types of errors, but that log those errors somewhere? That way you get an application that doesn't crash unnecessarily, but you also get early and specific warning of bugs. Of course, they can also test for conditions they can't handle, and stop then and there. Assertions, in other words.
This is a special case of a more general principle: discover bugs as early as possible. That's why I like strong typing and similar features that move discovery from run-time to compile-time. Assertions similarly can discover bugs much closer to their source, before knock-on effects cause odd failures or crashes elsewhere.
Ideally, everyone would use assertions liberally, but in practice we tend not to bother until we hit an awkward bug...
The same applies to testing, too. We should do thorough and disciplined testing, but in practice we don't bother. It is true, though, that some types of application or library are several orders of magnitude easier to test than others. Automated test suites that are easy to write for text-only, non-interactive, single-threaded, single-tier code tend not to work so well when the code involves many threads on many different machines, GUIs, complex DB state, &c...
In theory, that's a great idea. But it would be hard indeed to force them to reveal enough to be meaningful.
They'd have to release the formats/protocols at least six months or so before releasing the software, to prevent other developers playing continual catch-up. (Without changing them in the interim, of course.) And they'd have to be prevented somehow from hiding details that might allow subtle incompatibilities, later lock-in, or other preferential treatment. Ideally, they'd be made to release an open-source reference implementation, too.
And they'd have to show that implementing the protocol or using the format didn't infringe any patents -- not just that a patent-free method was available, but that M$ couldn't use a better, patent-encumbered method unavailable to their competitors. And that they couldn't file such patents in the future.
And so on. Time and time again, companies have learned that you can't play M$ on their own terms and break even, let alone win. They've learned a whole battery of techniques to steal an unfair advantage. And blocking them all is no easy task.
if you don't like what MS does then switch to Mac OS X or Linux and put your money where your mouth is!
If only more people actually did this! If even 10% of the people who complained about M$ actually did something about it, the software world would be a very different place. It's amazing the number of people who feel that they are a special case, that they have a particular special reason for not switching to something else. (Yes, in some cases those reasons are genuine, but I suspect laziness plays a large part in many.)
I try to act on principle. I've only ever owned two pieces of M$ software, for example: one was the Psion Series 3 version of AutoRoute (which doesn't really count as it was written by a separate company that got bought out shortly before release; M$ dropped it soon after), and the Mac OS X version of IE (pre-installed; I keep it as a last-resort browser and use it every few months). It's not hard, really -- it's a pain when people keep sending me Word documents, but there are various workarounds even if people won't take the hint -- and I don't feel I'm making any great sacrifices. I just don't put following the crowd as my top priority.
So, to all you people who use M$ software and complain about it: don't complain, STOP USING IT!
Indeed. Bytecode has two major advantages -- platform independence, and security. Does anyone find it ironic that in implementing their bytecode, M$ clearly missed both points?
I'm guessing that, for example, getting two voices per staff would be easier in a GUI system than having to manage the text input
Actually, polyphony is one of those areas where LilyPond scores (ha!) rather highly. Straight parallel-part writing is easy enough; you can either enter the two parts separately, or combine them as chords or interspersed parts. But it excels where notes overlap and combine in ad-hoc, shifting ways, such as complex piano music. LilyPond makes it easy to describe this sort of thing, to arbitrary complexity, with chords/clusters, nested parts, small- as well as large-scale parallelism, and the ability to create/use/destroy extra parts as you go along. Even in my (so far only) experiment with arranging a piano part, I found I'd naturally written stuff that even a complex GUI package just wouldn't be able to do.
Your general point is sort of valid, though. I believe there are several GUIs which can output LilyPond format, some dedicated and some more general, and it also comes with convertors from MIDI, ABC, and other popular formats. So you could easily write and/or enter music some other way, and then use LilyPond for the final engraving (which seems to be its aim). OTOH, its own text format is straightforward enough for what it does, and I personally look forward to using it some more. Whatever works for you, I guess.
I wonder how many musicians today can actually read music.
It doesn't matter that some musicians don't read music. Some musicians can't play keyboard. Some can't sing. Some software developers don't know C!
What matters is that a good number can. I do all sorts: I've written music for a choir, played bass in the theatre, sung solos and chorus parts in in rock shows and classical concerts, I play keyboard in a band, and lots more. And almost all of it all takes printed music. Yes, sometimes I can get away with bar charts and chord symbols; sometimes I learn from recordings and lyrics; sometimes I enter music with a piano-roll editor. But I still use music notation more than everything else put together, and so do most of the people I make music with. It's the most accurate, portable and compatible way of communicating music, and there's still a huge demand for it. Yes, some musicians can't read music. Neither can some drummers [fx: ducks]. But Hovis aren't going out of business because some people don't eat bread, and neither are score-writing packages of various kinds.
I'm just getting started with LilyPod (I've completed one piece, and working on a couple of others), and I can tell you that it's much the best output I've seen, well worth the extra effort. Many packages will get you half-way there fairly easily, but half-way there does not look good. It's like comparing old, crude monospaced dot-matrix text with professional print -- it conveys roughly the same information, but it's much harder to follow and makes you work for it. Some packages can even get 90% of the way there (e.g. Cubase Score, Sibelius), but the last 20% of that takes forever, tweaking and adjusting and cursing, and the result is fragile. Only LilyPond can get the final 10% of the way there -- in a simple, robust way, producing output that looks like a piece of music rather than a bunch of music symbols on a page.
LilyPond isn't perfect. It's hard to learn even for an experiencer programmer like me; and it has trouble with complex vocal scores (e.g. where vocal lines combine or split, or switch between sharing staves and/or lyrics and each having their own; can anyone help with these cases?). But its output is far more, well, musical than anything else I've seen.
Use whatever notation or package is most useful to you. You don't have to use standard music notation, or LilyPond, if you don't want to. But there are plenty of us who do; isn't that what matters?
OT, but does anyone else find it odd that we talk of 'billion kilometres' when there's the perfectly sensible unit 'terametres' we could be using instead? (Alternatively, if you find simpler units better, doesn't 'trillion metres' qualify?) The S.I. system is designed specifically for such things!
Is it any good? I spotted it a while back and it looked promising.
People here (UK) seem to have various views on it I suspect that, although using it might be legal under the laws of the hosting country, using it here might be against UK law. Also, it doesn't seem as if the artists get to benefit. So there are both legal and moral questions marks over it. Anyone know more?
What would happen: software would take an order of magnitude or two longer to specify, design, write and test. Also, it would probably have to use similarly-specified tools, and run on a similarly-specified platform.
I can see two possible outcomes:
The software engineers get given the time and resources they need, and high-quality software (eventually) results. (I believe this already happens in certain high-risk environments.)
Management sees similar software getting made for less, calls the estimates bloated, and insists on getting it made quicker and cheaper. 99% of the time, they'll seem right; the other 1%, they'll blame the engineers for not doing their job properly.
The solution to that particular problem is to switch shells to zsh -- with its powerful recursive file completion you never need find again!
But yes, manpages are often cryptic, and tend describe the rare complex cases at the expense of the more common, simple ones. A few simple examples would go a long way in most cases.
Singing lessons are generally aimed at singing solo, which (though great fun if you can do it) won't really help socialisation. However, if it leads to singing in groups, that might do some good.
Acting may well be a better bet. I wish I'd done some acting classes, in fact -- I've got involved in musical theatre as a singer and musician, and although I can act out solo parts easily enough, I find having to interact with (and especially react to) other performers much harder. (Not that I have Asperger's, you understand, just the stereotypical geek personality...)
many of her students just can't get it into their heads why a random page on the internet should not be given as much weight as an expert in the field. She has gone over it with them, but they are lazy
Maybe she should set them a fairly obscure topic to research, having set up a plausible-looking but extremely inaccurate page on the subject for them to get snared by! Sometimes people only learn from their mistakes...
The only plausible advice I've heard is to make sure you get up at the same time each day, regardless of when you went to bed. The theory is that the next night you'll be so tired you will sleep. But that takes a lot of willpower...
I know strong light at a particular time of day is supposed to help adjust your circadian rhythms. Anyone know when, and if it works?
Slashdot Mirror
To be fair, I think you'd have a hard time arguing that's the case. These governments don't have anything wrong with sex per se -- people are free to talk about it all the time, for example, just as we're doing now, and there aren't too many restrictions on actually doing it. The problem is with certain manifestations of sex: in particular, with images of people actually engaging in it. And not all the arguments that sex is perfectly natural and healthy and people have been doing it for tens of thousands of years apply to that particular manifestation.
Not that I'm saying it's wrong, just that more general case isn't always relevant.
Which is exercising free will, then -- passively looking at every web site you come across (pun intended), or choosing which web sites you'd like to visit?
(And of course it's bound to fail anywhere outside the US. (And yes, I'm going to keep having a grump about this :) )
iTunes is an app. It's a good way to organise and play your music. You may or may not like it, but you can use it without going near the iTMS. (I do -- the latter isn't even available here...) You can use it to manage MP3 downloaded from Magnatune or anywhere else.
Sorry to go on about this, but this misunderstanding seems to be spreading...
If the repository is not public, then how is it open source?
Open source does not necessarily mean that everyone has access to the source. It means that everyone who has access to the binary also has access to the source.
That's a very different proposition, but it's enough to ensure code freedom. (For common values of 'freedom', anyway.) That's how companies can legally modify open-sourced software for their internal use without releasing it. For that matter, that's how I'm able to modify open-sourced software for my private use without releasing it!
What if cars came without a body shell, and you either got hot/cold/wet/windy driving, or had to hunt around for one of umpteen different body shells, most of which clashed with the car interior, many of which didn't fit properly and got in the way of the instruments or doors, and all of which let in draughts?
And, presumably, a permanent net connection? With a static IP address? And your own domain?
How many users does that apply to, do you think?
On the one hand, plain 7-bit ASCII text is the single most compatible format; just about any platform and app can handle it in some way or other. And it's likely to last longer than almost any other format. So as Gutenberg says, it's the most accessible format and the most future-proof.
But on the other, it's very thin. It has no structure: nothing to separate chapters, scenes, volumes, &c. It has no metadata: nothing to identify authors, translators, editions, dates, even titles, in a machine-readable manner. And it has no way to represent accented characters, directional quotes, and other characters that would greatly improve the typography.
The compelling argument for me, though, is that although you could automatically convert from a standardised rich format to plain text, it's impossible to convert the other way around without lots of manual work. If Gutenberg had chosen a rich format, even a very simple one, to start with, then all the benefits of plain text would come with that almost for free -- a simple open-sourced program would let people convert from the one to the other, and they could even provide both versions of texts on their web site.
FWIW, for my own reading I keep files in plain text but formatted in a particular manner: in Windows Latin-1, with accents and typography; with Palm-style bookmarks; and with conventions for chapter/scene/volume breaks, bold/italics, and metadata. It's a pain getting them there, but means they're ideal for reading on my palmtop, and also capable of being up-converted if the need arises.
Isn't the solution to have libraries that are safe, spotting and handling many types of errors, but that log those errors somewhere? That way you get an application that doesn't crash unnecessarily, but you also get early and specific warning of bugs. Of course, they can also test for conditions they can't handle, and stop then and there. Assertions, in other words.
This is a special case of a more general principle: discover bugs as early as possible. That's why I like strong typing and similar features that move discovery from run-time to compile-time. Assertions similarly can discover bugs much closer to their source, before knock-on effects cause odd failures or crashes elsewhere.
Ideally, everyone would use assertions liberally, but in practice we tend not to bother until we hit an awkward bug...
The same applies to testing, too. We should do thorough and disciplined testing, but in practice we don't bother. It is true, though, that some types of application or library are several orders of magnitude easier to test than others. Automated test suites that are easy to write for text-only, non-interactive, single-threaded, single-tier code tend not to work so well when the code involves many threads on many different machines, GUIs, complex DB state, &c...
They'd have to release the formats/protocols at least six months or so before releasing the software, to prevent other developers playing continual catch-up. (Without changing them in the interim, of course.) And they'd have to be prevented somehow from hiding details that might allow subtle incompatibilities, later lock-in, or other preferential treatment. Ideally, they'd be made to release an open-source reference implementation, too.
And they'd have to show that implementing the protocol or using the format didn't infringe any patents -- not just that a patent-free method was available, but that M$ couldn't use a better, patent-encumbered method unavailable to their competitors. And that they couldn't file such patents in the future.
And so on. Time and time again, companies have learned that you can't play M$ on their own terms and break even, let alone win. They've learned a whole battery of techniques to steal an unfair advantage. And blocking them all is no easy task.
If only more people actually did this! If even 10% of the people who complained about M$ actually did something about it, the software world would be a very different place. It's amazing the number of people who feel that they are a special case, that they have a particular special reason for not switching to something else. (Yes, in some cases those reasons are genuine, but I suspect laziness plays a large part in many.)
I try to act on principle. I've only ever owned two pieces of M$ software, for example: one was the Psion Series 3 version of AutoRoute (which doesn't really count as it was written by a separate company that got bought out shortly before release; M$ dropped it soon after), and the Mac OS X version of IE (pre-installed; I keep it as a last-resort browser and use it every few months). It's not hard, really -- it's a pain when people keep sending me Word documents, but there are various workarounds even if people won't take the hint -- and I don't feel I'm making any great sacrifices. I just don't put following the crowd as my top priority.
So, to all you people who use M$ software and complain about it: don't complain, STOP USING IT!
Indeed. Bytecode has two major advantages -- platform independence, and security. Does anyone find it ironic that in implementing their bytecode, M$ clearly missed both points?
Actually, polyphony is one of those areas where LilyPond scores (ha!) rather highly. Straight parallel-part writing is easy enough; you can either enter the two parts separately, or combine them as chords or interspersed parts. But it excels where notes overlap and combine in ad-hoc, shifting ways, such as complex piano music. LilyPond makes it easy to describe this sort of thing, to arbitrary complexity, with chords/clusters, nested parts, small- as well as large-scale parallelism, and the ability to create/use/destroy extra parts as you go along. Even in my (so far only) experiment with arranging a piano part, I found I'd naturally written stuff that even a complex GUI package just wouldn't be able to do.
Your general point is sort of valid, though. I believe there are several GUIs which can output LilyPond format, some dedicated and some more general, and it also comes with convertors from MIDI, ABC, and other popular formats. So you could easily write and/or enter music some other way, and then use LilyPond for the final engraving (which seems to be its aim). OTOH, its own text format is straightforward enough for what it does, and I personally look forward to using it some more. Whatever works for you, I guess.
It doesn't matter that some musicians don't read music. Some musicians can't play keyboard. Some can't sing. Some software developers don't know C!
What matters is that a good number can. I do all sorts: I've written music for a choir, played bass in the theatre, sung solos and chorus parts in in rock shows and classical concerts, I play keyboard in a band, and lots more. And almost all of it all takes printed music. Yes, sometimes I can get away with bar charts and chord symbols; sometimes I learn from recordings and lyrics; sometimes I enter music with a piano-roll editor. But I still use music notation more than everything else put together, and so do most of the people I make music with. It's the most accurate, portable and compatible way of communicating music, and there's still a huge demand for it. Yes, some musicians can't read music. Neither can some drummers [fx: ducks]. But Hovis aren't going out of business because some people don't eat bread, and neither are score-writing packages of various kinds.
I'm just getting started with LilyPod (I've completed one piece, and working on a couple of others), and I can tell you that it's much the best output I've seen, well worth the extra effort. Many packages will get you half-way there fairly easily, but half-way there does not look good. It's like comparing old, crude monospaced dot-matrix text with professional print -- it conveys roughly the same information, but it's much harder to follow and makes you work for it. Some packages can even get 90% of the way there (e.g. Cubase Score, Sibelius), but the last 20% of that takes forever, tweaking and adjusting and cursing, and the result is fragile. Only LilyPond can get the final 10% of the way there -- in a simple, robust way, producing output that looks like a piece of music rather than a bunch of music symbols on a page.
LilyPond isn't perfect. It's hard to learn even for an experiencer programmer like me; and it has trouble with complex vocal scores (e.g. where vocal lines combine or split, or switch between sharing staves and/or lyrics and each having their own; can anyone help with these cases?). But its output is far more, well, musical than anything else I've seen.
Use whatever notation or package is most useful to you. You don't have to use standard music notation, or LilyPond, if you don't want to. But there are plenty of us who do; isn't that what matters?
Nuts to your white mice.
OT, but does anyone else find it odd that we talk of 'billion kilometres' when there's the perfectly sensible unit 'terametres' we could be using instead? (Alternatively, if you find simpler units better, doesn't 'trillion metres' qualify?) The S.I. system is designed specifically for such things!
People here (UK) seem to have various views on it I suspect that, although using it might be legal under the laws of the hosting country, using it here might be against UK law. Also, it doesn't seem as if the artists get to benefit. So there are both legal and moral questions marks over it. Anyone know more?
I can see two possible outcomes:
- The software engineers get given the time and resources they need, and high-quality software (eventually) results. (I believe this already happens in certain high-risk environments.)
- Management sees similar software getting made for less, calls the estimates bloated, and insists on getting it made quicker and cheaper. 99% of the time, they'll seem right; the other 1%, they'll blame the engineers for not doing their job properly.
Which do you think more likely?But yes, manpages are often cryptic, and tend describe the rare complex cases at the expense of the more common, simple ones. A few simple examples would go a long way in most cases.
Acting may well be a better bet. I wish I'd done some acting classes, in fact -- I've got involved in musical theatre as a singer and musician, and although I can act out solo parts easily enough, I find having to interact with (and especially react to) other performers much harder. (Not that I have Asperger's, you understand, just the stereotypical geek personality...)
I suspect you mean such a specious argument :)
Maybe she should set them a fairly obscure topic to research, having set up a plausible-looking but extremely inaccurate page on the subject for them to get snared by! Sometimes people only learn from their mistakes...
The only plausible advice I've heard is to make sure you get up at the same time each day, regardless of when you went to bed. The theory is that the next night you'll be so tired you will sleep. But that takes a lot of willpower...
I know strong light at a particular time of day is supposed to help adjust your circadian rhythms. Anyone know when, and if it works?
Of course, some of us have enough trouble doing that even without caffeine... :-(