> > The music itself is not copyrighted. > > Oh please, where DID you get this notion.
The vast bulk of the repertoire is not copyrighted. That's not particularly controversial.
I grant you that in the context of living composers copyright is a factor. I still doubt it's an important driver. Most composers depend primarily on commission, not sheet-music/performance residuals.
This is all pretty much moot though. The sheet music publishers occupy a very small niche, essentially ma & pa operations. They would likely survive without copyright, and they certainly don't drive the viability of orchestras.
In the context of the grandparent post, this is doubly moot. Your point is about composers, not orchestras. I find the concept that orchestras depend on copyright for survival to be obviously false.
If someone can tell who you voted for, your vote is completely worthless and should not be counted at all. This is clearly an overstatement regarding a legitimate principle.
If I tell my friends who I voted for, that does not render my vote invalid?
A more genericly applicable example, most polls have a "straight ticket" option. If a voter spends a short time in the polling station I can be quite confident that they voted "straight ticket", and the only thing I need to guess is "which direction".
Yes votes should be secret, but automatic disqualification without context amounts to disenfranchisement, something that is a much greater issue.
I like Asterisk just fine, and I think VOIP has a bright future, but....
How do you think the phone company delivers your lines to you? In most cases, it's VoIP over an ATM circuit
Can you back this up?
I think not.
It does not pass a series of smell tests, two for example:
why would the phone company throw away their existing technology (5ESS)?
Why would you jump from TDM (ATM) to IP, and then back again, introducing more failure points, more complexity, and the weaknesses of both approaches in one package?
There are certain niche long distance companies who make heavy use of VOIP, but specific economics drive those decisions (international termination rates etc). No RBOC is using voip for local service (and T1 to channel bank is strictly for CLECS).
While I was in college in the 80s, Apple was extremely succesful selling to schools. Signifigantly better then half the computers sold were Macs. I asked the software buyer for the independent bookstore why PC software had a much stronger presence on the shelves. Did it sell proportionally better. He told me that his suppliers stocked very little Mac software and that he sold all that he could get. . The EE school at the time was requiring all of it's students to buy a Mac (they were using them to extend their Apollo workstations). Less then 30 feet from the main EE building was a B Dalton that stocked No Mac books at all (at the time, B Dalton was a good source of Mac Programming books in Des Moines). I asked them why they stocked no Mac programming books (let alone no Mac books). They told me that buying decisions were made in Indianapolis and they had no control.
The "market" dications are hardly clear...
Re:Why are we hiding from the police, daddy?
on
Vim 6.4 Released
·
· Score: 1
..having to move my hands to reach the Esc key all the time. Does anybody here know of an alternative?
Any real problem, and it's like finding a needle in a haystack. grep is a much more useful tool in sorting out what's going on.
To be fair, the Windows Event Log GUI has a filtering mechanism, but I find grep to be much easier to use in practice. Further, the filtering mechanism is limited to the logging services notion of catagories ("Source" "Event Catagory", "Severity" "System"). Most of the time that I need to troubleshoot problems these catagories obscure rather then help. Real problems rarely are neatly catagroized. On the other hand, grepping on a relevant substring, and ALL the appropriate messages come up.
grep is dirt simple to use. Absurdly simpler then the GUI (though not as pretty).
For what it's worth the excellent folks at sysinternals (ne wininternals) have a grepable version of the event log.
I routinely get fax blasters calling me from bogus numbers like "987-654-3210" (yeah, like THAT isn't obvious, sheesh). Requires no specialized equipment at all on your part.
Is the spoofed number on the fax printout? or di you have a callerid box on the fax line?
If it's on the printout, it has zero reliability. Whats printed out is programmed into the fax machine, and is often wrong/out-of-date. It has no relationship to the phone system at all.
You need hardware, but that is not the limiting factor. It's a protocol issue and involves your telco provider.
CallerID is a "read only" protocol. It's pushed downstream, but there is no upstream reciever.
The underlying protocol is ANI (automatic Number ID). You can get a variety of T1's that support ANI in some form, the most common being PRI ISDN.
Just having this is not enough. Your provider has to accept the digits you claim as originating. Most provider will NOT accept end user provided origination. There are a lot of reasons for this. Here are a few that spring to mind.
1) 911 network. The ANI is passed to the 911 system so that a given 911 call has a geographic location.
2) Trust and abuse. The services linked in the parent post make this clear. Legit users almost never have compelling need to claim to be another number.
3) possible billing issues. Phone number is a findamental billing/tracking entity in most telco systems. Allowing customers to present numbers could possibly cause uninetended problems.
Everyone else here seems to be taking this at face value. I think there are at least two fundamentally flawed assumptions.
1) Ten years is a good time-frame.
2) "Thin Client" is the major parameter.
Instead I proffer:
1) 40 years is probably more realistic. In that time frame a variety of approaches have been "standard". In particular, Terminals ruled for many years.
2) The real issue is centralized control vs. end-user control.
Even in the ten year time frame winkydink implies, there have been various paradigm shifts. Most movement these days is toward more centralized management:
a) MS is looking to sell service rather then software.
b) Web based applications keep gaining momentum.
c) PC hardware sales are stagnant, computing appliance segments continue to expand.
And yes, X-Teminals, Diskless Workstation (and even TS clients) still are widely used....
The article indicated that the result was shocking. I worked for a company that was competing against direct mail. A good response rate for direct mail was 2-4% (thats "response" as in "mails something back). Now, I suppose there is less "friction" involved in clicking on a link, but the notion that spam is orders of magnitude more effective then direct mail sets off the warning bells. It doesn't pass the "smell test".
The article does not indicate sample size or methodology. Nor does it indicate much about motivation of the study. There could well be something there, but there is ample reason to doubt it.
Instead of a single 1000 line C program, you have a basket of C programs and a basket of programs in different "scripting" languages... And this is better than a single C program?
For what the original poster outlined, I'm certain that's the case.
The core idea is "modular programming". There are a whole raft of advantages. And a large body thinking to support it.
UN*X is built on this idea. Typical development cycle (see "the unix programming environment)... 1) mock it up in shell 2) redo it 3) Use C to speed up the slow parts if needed. 4) write a library if it's used enough.
Hard to tell exactly where you are headed here, but the unix server will start as many as you want. WinVNC is limited to one port (per instance) but there are hacks (very crude) that allow you to replace the windows shell to...
So you'd need to do something that would grab the connection start a new VNC server and hand the display to that client.
and tie it to user login. There used to be one at the UltraVNC client site, but that appears to have died out
Unix VNC can be set up to replace X as well (gdm as the initial X-app) so one port can handle multiple logins.
Again, I have yet to see a wall wort fail, but I've seen many power supplies fail.
We see wall-worts fail all the time. We have about 700 DSL variant CPEs and wall-worts are the largest single source of failure.
Now, this is still on the anecdotal level.
It occurs to me, do your wall-wort VS power-supply cases overlap precisely? Without knowing further, I'd venture the guess that your wall-wort experiences are personal, and your power-supply experiences are client/employment related, a far larger set. On a personal equipment I have never seen either fail.
This is a good example of differing aims. The autoupdate feature is a huge feature to larger operations. CPanel basically administers a farm of hosting appliances for you, thus saving a lot of local administration. If you want custom software, you need to think very carefully about what it is that your customer is buying and what it is taht you want to support.
Slashdot Mirror
Fair enough.
But...
In that scenario, the developer has nothing to lose on open-sourcing it either. The same dynamics apply, whether MS Access or Open-Source.
This is essentially the "support" model. It's an old model, and it is not a mass market model
You might try mono...
> > The music itself is not copyrighted.
>
> Oh please, where DID you get this notion.
The vast bulk of the repertoire is not copyrighted. That's not particularly
controversial.
I grant you that in the context of living composers copyright is a factor. I
still doubt it's an important driver. Most composers depend primarily on
commission, not sheet-music/performance residuals.
This is all pretty much moot though. The sheet music publishers occupy a very
small niche, essentially ma & pa operations. They would likely survive without copyright, and they certainly don't drive the viability of orchestras.
In the context of the grandparent post, this is doubly moot. Your point is about
composers, not orchestras. I find the concept that orchestras depend on
copyright for survival to be obviously false.
Copyright has almost NO place in classical music.
The music itself is not copyrighted.
Copyright produces almost NO revenue stream.
Classical music lives on performance subscriptions and donations. It has far more in common with your garage band then commercial music.
If I tell my friends who I voted for, that does not render my vote invalid?
A more genericly applicable example, most polls have a "straight ticket" option. If a voter spends a short time in the polling station I can be quite confident that they voted "straight ticket", and the only thing I need to guess is "which direction".
Yes votes should be secret, but automatic disqualification without context amounts to disenfranchisement, something that is a much greater issue.
. Sure, AMD and Intel just want your cash, but you really get something in return for it. Nobody can say that about Nike with a straight face.
Status, a pretty marketable commodity...
Can you back this up?
I think not.
It does not pass a series of smell tests, two for example:
There are certain niche long distance companies who make heavy use of VOIP, but specific economics drive those decisions (international termination rates etc). No RBOC is using voip for local service (and T1 to channel bank is strictly for CLECS).
While I was in college in the 80s, Apple was extremely succesful selling to schools. Signifigantly better then half the computers sold were Macs. I asked the software buyer for the independent bookstore why PC software had a much stronger presence on the shelves. Did it sell proportionally better. He told me that his suppliers stocked very little Mac software and that he sold all that he could get.
.
The EE school at the time was requiring all of it's students to buy a Mac (they were using them to extend their Apollo workstations). Less then 30 feet from the main EE building was a B Dalton that stocked No Mac books at all (at the time, B Dalton was a good source of Mac Programming books in Des Moines). I asked them why they stocked no Mac programming books (let alone no Mac books). They told me that buying decisions were made in Indianapolis and they had no control.
The "market" dications are hardly clear...
Yep!
CNT-[ is escape.
That counts (arbitrary date aside). If a language is still used and still influential after that long a time, it is a success, regardless of numbers.
FORTRAN is likewise a success. Pascal less so.
awk....
awk is pretty cool....
sgrep, while not geared at binary data, is quite useful in this regard. It's a great little utility, worth adding to shell bag'o'tricks.
sgrep '"start_string"
That's funny, I hate the windows logging GUI....
Any real problem, and it's like finding a needle in a haystack. grep is a much more useful tool in sorting out what's going on.
To be fair, the Windows Event Log GUI has a filtering mechanism, but I find grep to be much easier to use in practice. Further, the filtering mechanism is limited to the logging services notion of catagories ("Source" "Event Catagory", "Severity" "System"). Most of the time that I need to troubleshoot problems these catagories obscure rather then help. Real problems rarely are neatly catagroized. On the other hand, grepping on a relevant substring, and ALL the appropriate messages come up.
grep is dirt simple to use. Absurdly simpler then the GUI (though not as pretty).
For what it's worth the excellent folks at sysinternals (ne wininternals) have a grepable version of the event log.
Is the spoofed number on the fax printout? or di you have a callerid box on the fax line?
If it's on the printout, it has zero reliability. Whats printed out is programmed into the fax machine, and is often wrong/out-of-date. It has no relationship to the phone system at all.
You need hardware, but that is not the limiting factor. It's a protocol issue and involves your telco provider.
CallerID is a "read only" protocol. It's pushed downstream, but there is no upstream reciever.
The underlying protocol is ANI (automatic Number ID). You can get a variety of T1's that support ANI in some form, the most common being PRI ISDN.
Just having this is not enough. Your provider has to accept the digits you claim as originating. Most provider will NOT accept end user provided origination. There are a lot of reasons for this. Here are a few that spring to mind.
1) 911 network. The ANI is passed to the 911 system so that a given 911 call has a geographic location.
2) Trust and abuse. The services linked in the parent post make this clear. Legit users almost never have compelling need to claim to be another number.
3) possible billing issues. Phone number is a findamental billing/tracking entity in most telco systems. Allowing customers to present numbers could possibly cause uninetended problems.
Everyone else here seems to be taking this at face value. I think there are at least two fundamentally flawed assumptions.
1) Ten years is a good time-frame.
2) "Thin Client" is the major parameter.
Instead I proffer:
1) 40 years is probably more realistic. In that time frame a variety of approaches have been "standard". In particular, Terminals ruled for many years.
2) The real issue is centralized control vs. end-user control.
Even in the ten year time frame winkydink implies, there have been various paradigm shifts. Most movement these days is toward more centralized management:
a) MS is looking to sell service rather then software.
b) Web based applications keep gaining momentum.
c) PC hardware sales are stagnant, computing appliance segments continue to expand.
And yes, X-Teminals, Diskless Workstation (and even TS clients) still are widely used....
The article indicated that the result was shocking. I worked for a company that was competing against direct mail. A good response rate for direct mail was 2-4% (thats "response" as in "mails something back). Now, I suppose there is less "friction" involved in clicking on a link, but the notion that spam is orders of magnitude more effective then direct mail sets off the warning bells. It doesn't pass the "smell test".
The article does not indicate sample size or methodology. Nor does it indicate much about motivation of the study. There could well be something there, but there is ample reason to doubt it.
For what the original poster outlined, I'm certain that's the case.
The core idea is "modular programming". There are a whole raft of advantages. And a large body thinking to support it.
UN*X is built on this idea. Typical development cycle (see "the unix programming environment)...
1) mock it up in shell
2) redo it
3) Use C to speed up the slow parts if needed.
4) write a library if it's used enough.
This is more of a nit pick, but I can think of a few interpreted languages geared at serious crunching.
APL -- serious number crunching is the only reason people use it.
PIK (Ok, it's a whole environtment, not just an interpreter) -- Lots of record crunching gets done by PIK systems.
Hard to tell exactly where you are headed here, but the unix server will start as many as you want. WinVNC is limited to one port (per instance) but there are hacks (very crude) that allow you to replace the windows shell to...
and tie it to user login. There used to be one at the UltraVNC client site, but that appears to have died out
Unix VNC can be set up to replace X as well (gdm as the initial X-app) so one port can handle multiple logins.
How does Xen compare to Plex86?
We see wall-worts fail all the time. We have about 700 DSL variant CPEs and wall-worts are the largest single source of failure.
Now, this is still on the anecdotal level.
It occurs to me, do your wall-wort VS power-supply cases overlap precisely? Without knowing further, I'd venture the guess that your wall-wort experiences are personal, and your power-supply experiences are client/employment related, a far larger set. On a personal equipment I have never seen either fail.
The exchange rate accounts for most of this. Your example is fundamentally flawed.
Ironically, this would increase the price/local_wage ratio for XP etc.
This is a good example of differing aims. The autoupdate feature is a huge feature to larger operations. CPanel basically administers a farm of hosting appliances for you, thus saving a lot of local administration. If you want custom software, you need to think very carefully about what it is that your customer is buying and what it is taht you want to support.
Then there is the job ads that request such nonsense....