Indeed it does. Just as USB and Firewire struggled in the beginning, so it goes with Bluetooth. Apple has picked up the torch, however, so I expect that in a couple of years there will be plenty of PCs (especially notebooks) that support it.
The company my father works for has an MTA that wouldn't let him send mail with the word "Dick" in it. It bounced it back to him explaining that it might be offensive.
As in Dear Dick, We enjoyed dinner the other evening...
In which case you [arguably] already have access to the best damn OO development system on the planet. I strongly recommend you go out and buy Aaron Hillegass' book on Cocoa programming and enjoy yourself.
Yea, I don't know what that's about. I was posting a legitimate gripe about the language, or at least the way my professor is teaching it. I'll have to take a look at Python.
Python is neat, but I don't know if I'd recommend it. I do hear that Ruby it bitchin'. If you'd like to check out a clean C extension, maybe take a look at GNUStep, which is Obj-C based: http://www.gnustep.org
Or, if you can drop the $'s, buy a Mac and check out Cocoa development. It's similar to gnustep (they come from the same roots, after all). Careful, though. If you do, you'll never want to go back.
If it added keywords, then it's not 100% backwards compatible. So there you go.
If it were 100% backward compatible, it couldn't add features, could it? I do believe that it is 100% FORWARD compatible, however. The keywords added were not valid C syntax (I'm pretty sure this is entirely true) - they are words like @class, @interface, @implementation, and the method calls are [someinstance doSomething:param1 with:param2]. Which can never be confused with valid C syntax, unlike C++, right?
Aren't there problems with some unions and structs that are valid in C, but not in C++?
I'm not aware of any C (not C99) code that a standard compliant C++ compiler won't compile, with the exception of one that uses C++ keywords. There may be some syntaxes that aren't legal in C++ anymore, but I'm not 100% sure.
Isn't that why C++ has to wrap some #include statements with the weird extern call?
full, unrestricted permissions to their own property.
So, what I'm saying is this: For most consumers, there are no restrictions. They can burn CDs. They can go portable on iPods. They can play the tunes on multiple machines.
Consumers (including you, I'd guess) use products with restrictions all the time. The important thing is that they don't get in the way.
It turns out that everyone has some level of comfort with DRM and "broken formats." Do you use DVD's? Cable? Satellite? All those are DRM'd to some extent. Just like Apple's DRM, the hope is that consumers (which may not include you, in which case producers don't much care) will find them acceptible.
Being able to burn music CDs from apple's downloads seems pretty reasonable. Certainly that covers most user's needs. What's more, you can share music on your LAN.
That would work, but it'll never be implementable as it would require a protocol change
This whole thread is based on the notion of protocol change!
IMHO, one of 2 things is going to happen: 1. The sendmail team will decide on some kind of authorizing protocol, and implement it. After which, everyone else will fall in line, good or bad. 2. M$ will tire of folks sending viruses spoofed from them, and THEY will implement a protocol enhancement/change.
If #2 happens, the open folks will whine and complain that M$ is breaking SMTP. The truth is it IS broken and nobody (at the top eg sendmail team) has decided to fix it. I'd say it's clear that it's needed fixing for at least 5 years now...
I have a laptop which travels with me. There are any number of places I go which have 'friendly lans' (friend's houses, mostly). Their SMTP server allows mail sent from their LAN, and is call - you guessed smtp.somelan.whatever.
But the mail I send is always "From kwerle@pobox.com" (note this is not even my domain, but my mail forwarder's).
All of this is totally convenient and reasonable. It would be MUCH better if the receiving server asked the from somedomain if the message was allowed to be sent "From somedomain", instead of having an address whitelist.
Not all machines are single-user. If you have 100 users, each using a dozen file handles, you hit the 1024-filehandle limit pretty quickly. This works out to 3 processes per user (filehandles to stdin, stdout, stderr, stdlog for each process).
Fair enough. I guess I'd never consider Linux for a multi-user system - though I do wonder what folks like IBM do for their linux servers... Do they really intend to serve multiple users, or do they intend to run a few database and web servers on them.
When you get right down to it... Who runs 'multi-user' system anymore? Where users actually "log in" and run programs as opposed to use services (web, fs, db, other). Hell, most ISP's don't even do that anymore.
but in this case I actually want the server to crash if there are too many processes at once - it's not a production server, and it will show me where I've been sloppy in my code.
Without knowing what you're doing...
If you're generating processes like that, I'd say you're already being sloppy in your code [design]. What are you doing that you need to generate lots of processes?
What's more, I'd expect that your machine would slow to a crawl before it had that many ACTIVE processes, though I guess even small boxes are pretty damn fast these days. If you have a 2Ghz box, that's still more than 15Mhz/process. Wow.
Yeah, my server is running FreeBSD. Next time around it will probably be OSX - I've not been happy with FreeBSD since around 2001, and OSX keeps getting better...
Set up a CGI server that knows people's email addresses. Anytime you want to post an address, use the cgi which does a mailto:yellowpages@yourdomain.com Subject: Please send me the email address for #TAG#
Which yellowpages@yourdomain.com answers (with the address in the body).
Maybe that's too much work, though...
I leave my address out in the open and use a spam filter...
The number of files you may have open is STILL an issue, even today, and even under linux...
Still a fact, yes. Still an issue, nope. Not for me, anyway. I haven't had to deal with it since the DOS days (in the next job, I did more complex work and did hit the limit. So I looked up the var, set it, and promptly forgot).
There are any number of limits in any number of OS's that I never intend to care about - RAM size, VM size, file size, # file open, # files on the system, # files in a directory. The point is this: I know those limits exist. I have notions of which ones can be easily changed. I'm NOT a system programmer, so I just don't care and shouldn't have to as long as I remember that there are limits and I shouldn't waste these resources.
Maybe this question was asked of you because you being considered for a promotion to a systems programming position?
No, he compiled a list of trivia questions to show what I didn't know. He did NOT expect me to point out how meaningless the questions were.
"Windows rolling along..." Hmmm. Actually, all versions of Windows prior to Windows 95 required a sensible value for this environment variable.
Exactly why it was becoming a non-issue. Default configs were fine.
Users, who didn't know any better, were routinely screwing around with this environment variable. And this could break your application programs.
Not at our job. Users were users who didn't know and didn't care. If something broke, someone fixed it for them and they were none the wiser.
As for whether the default was 3, or 8? It was ridiculously low.
For DOS, having 8 files open at the same time is really a pretty wild concept. Again, I was a developer and had never hit it (our project wasn't very complex, as I recall - 1 database and 3ish indexes).
And if I am ever going to lead a team doing MS-DOS development I'll be sure to bone up on the exact value.
And there we differ again - if I'm ever going to be lead on a team doing MS-DOS development, I'll be sure to tell them where they can stick their job:-) Thanks, but no thanks.
The answer is "3". The environment variable was NFILES.
Given that another followup says you got the number wrong, and
Frankly, I think it is a pretty reasonable question.
I don't think I'll be working for you:-)
Really, if it'd been a sysadmin job, I might agree with you. But what it boils down to is that it's a trivia question; the answer is in some book, and I just shouldn't need to care. Windows was rolling along anyway, and soon enough it wouldn't matter at all.
If he'd asked "what's recursion?", or "how would you implement a sort?", or "how do you debug memory issues?", that would have been appropriate.
It turns out I'm a good programmer, and I program in Java (most of the time, these days), but I can't remember how to write a main() method. What I do know is that if I fire up my copy of emacs and type 'main ', it will expand and fill in all the right trivia because I looked it up once and made sure I'd never have to remember again.
....guess that means that BSD supports it?
Indeed it does. Just as USB and Firewire struggled in the beginning, so it goes with Bluetooth. Apple has picked up the torch, however, so I expect that in a couple of years there will be plenty of PCs (especially notebooks) that support it.
I don't get it. You tried to get your ISP to do something reasonable? What were you thinking?
Projects like the one you describe are why the following exist:
stunnel
vtun
ssh
openvpn
http proxies
etc.
ONE of those should have solved the problem for you...
This is exactly the right kind of thing to do.
I use scp, and so the command I issue is
scp -c blowfish SomeFile me@TargetHost:/somepath
On my 11Mb/s 802.11 network I am capped by bandwidth, not by CPU.
The company my father works for has an MTA that wouldn't let him send mail with the word "Dick" in it. It bounced it back to him explaining that it might be offensive.
As in
Dear Dick,
We enjoyed dinner the other evening...
Already have a Mac.
In which case you [arguably] already have access to the best damn OO development system on the planet. I strongly recommend you go out and buy Aaron Hillegass' book on Cocoa programming and enjoy yourself.
Yea, I don't know what that's about. I was posting a legitimate gripe about the language, or at least the way my professor is teaching it. I'll have to take a look at Python.
:-)
Python is neat, but I don't know if I'd recommend it. I do hear that Ruby it bitchin'. If you'd like to check out a clean C extension, maybe take a look at GNUStep, which is Obj-C based:
http://www.gnustep.org
Or, if you can drop the $'s, buy a Mac and check out Cocoa development. It's similar to gnustep (they come from the same roots, after all). Careful, though. If you do, you'll never want to go back.
It may be that I'm biased
If it added keywords, then it's not 100% backwards compatible. So there you go.
.
If it were 100% backward compatible, it couldn't add features, could it? I do believe that it is 100% FORWARD compatible, however. The keywords added were not valid C syntax (I'm pretty sure this is entirely true) - they are words like @class, @interface, @implementation, and the method calls are
[someinstance doSomething:param1 with:param2]
Which can never be confused with valid C syntax, unlike C++, right?
Aren't there problems with some unions and structs that are valid in C, but not in C++?
I'm not aware of any C (not C99) code that a standard compliant C++ compiler won't compile, with the exception of one that uses C++ keywords. There may be some syntaxes that aren't legal in C++ anymore, but I'm not 100% sure.
Isn't that why C++ has to wrap some #include statements with the weird extern call?
Objective-C indeed attempted to be truly object-oriented. At the expense of adding new syntax and breaking compatibility with C.
... 1988?
C++ tried to be an improved C, adding various features including OOP while retaining full backward compatibility with C.
WOAH - 100% incorrect!
Obj-C is a true superset of C, unlike C++. Any C code will compile with a correct Obj-C compiler. It added a few keywords to implement Objects, etc.
C++ compilers, I understand, will not compile all C code (PLEASE correct me if I'm wrong).
I don't know how old Obj-C is, but I know that it was the basis for NeXT's first dev environment, which first shipped in
Object-oriented programming seems to be vastly overrated. Give me C or Perl anyday.
Yowch! C++ is horrible, convuluted, and vastly overrated. There are any number of languages that aren't. Java isn't great, though it could be.
Check out Python, Ruby, Objective-C, to name a few.
Bummer you got marked flamebait - I'm trashing that moderation and just had to follow-up.
...that the book is funnier than the review.
If I had mod points, you'd get 'em.
Instead I'm burnig karma saying "Me Too!!!"
Damn, but that was a terrible review.
Why give your money to RIAA members...
Because I want to hear Hendrix and Static-X.
full, unrestricted permissions to their own property.
So, what I'm saying is this:
For most consumers, there are no restrictions.
They can burn CDs.
They can go portable on iPods.
They can play the tunes on multiple machines.
Consumers (including you, I'd guess) use products with restrictions all the time. The important thing is that they don't get in the way.
It turns out that everyone has some level of comfort with DRM and "broken formats." Do you use DVD's? Cable? Satellite? All those are DRM'd to some extent. Just like Apple's DRM, the hope is that consumers (which may not include you, in which case producers don't much care) will find them acceptible.
Being able to burn music CDs from apple's downloads seems pretty reasonable. Certainly that covers most user's needs. What's more, you can share music on your LAN.
What more could a reasonable consumer want?
After using it for about 30 seconds, I have to agree. Hopefully there will be enough noise that Apple will "un-fix" this.
I use and administer squirrelmail on my system. I'm happy. My users are happy...
That would work, but it'll never be implementable as it would require a protocol change
This whole thread is based on the notion of protocol change!
IMHO, one of 2 things is going to happen:
1. The sendmail team will decide on some kind of authorizing protocol, and implement it. After which, everyone else will fall in line, good or bad.
2. M$ will tire of folks sending viruses spoofed from them, and THEY will implement a protocol enhancement/change.
If #2 happens, the open folks will whine and complain that M$ is breaking SMTP. The truth is it IS broken and nobody (at the top eg sendmail team) has decided to fix it. I'd say it's clear that it's needed fixing for at least 5 years now...
I have a laptop which travels with me. There are any number of places I go which have 'friendly lans' (friend's houses, mostly). Their SMTP server allows mail sent from their LAN, and is call - you guessed smtp.somelan.whatever.
But the mail I send is always "From kwerle@pobox.com" (note this is not even my domain, but my mail forwarder's).
All of this is totally convenient and reasonable. It would be MUCH better if the receiving server asked the from somedomain if the message was allowed to be sent "From somedomain", instead of having an address whitelist.
Not all machines are single-user. If you have 100 users, each using a dozen file handles, you hit the 1024-filehandle limit pretty quickly. This works out to 3 processes per user (filehandles to stdin, stdout, stderr, stdlog for each process).
Fair enough. I guess I'd never consider Linux for a multi-user system - though I do wonder what folks like IBM do for their linux servers... Do they really intend to serve multiple users, or do they intend to run a few database and web servers on them.
When you get right down to it... Who runs 'multi-user' system anymore? Where users actually "log in" and run programs as opposed to use services (web, fs, db, other). Hell, most ISP's don't even do that anymore.
kwerle@pobox.com
but in this case I actually want the server to crash if there are too many processes at once - it's not a production server, and it will show me where I've been sloppy in my code.
Without knowing what you're doing...
If you're generating processes like that, I'd say you're already being sloppy in your code [design]. What are you doing that you need to generate lots of processes?
What's more, I'd expect that your machine would slow to a crawl before it had that many ACTIVE processes, though I guess even small boxes are pretty damn fast these days. If you have a 2Ghz box, that's still more than 15Mhz/process. Wow.
Yeah, my server is running FreeBSD. Next time around it will probably be OSX - I've not been happy with FreeBSD since around 2001, and OSX keeps getting better...
Set up a CGI server that knows people's email addresses. Anytime you want to post an address, use the cgi which does a mailto:yellowpages@yourdomain.com
Subject: Please send me the email address for #TAG#
Which yellowpages@yourdomain.com answers (with the address in the body).
Maybe that's too much work, though...
I leave my address out in the open and use a spam filter...
So I'm curious: what OS are you using, and how many processes are we talking about?
If the money is right, I'll subcontract it and not touch a line of the code. I have better things to do with my time.
The number of files you may have open is STILL an issue, even today, and even under linux...
Still a fact, yes. Still an issue, nope. Not for me, anyway. I haven't had to deal with it since the DOS days (in the next job, I did more complex work and did hit the limit. So I looked up the var, set it, and promptly forgot).
There are any number of limits in any number of OS's that I never intend to care about - RAM size, VM size, file size, # file open, # files on the system, # files in a directory. The point is this: I know those limits exist. I have notions of which ones can be easily changed. I'm NOT a system programmer, so I just don't care and shouldn't have to as long as I remember that there are limits and I shouldn't waste these resources.
Maybe this question was asked of you because you being considered for a promotion to a systems programming position?
:-) Thanks, but no thanks.
No, he compiled a list of trivia questions to show what I didn't know. He did NOT expect me to point out how meaningless the questions were.
"Windows rolling along..." Hmmm. Actually, all versions of Windows prior to Windows 95 required a sensible value for this environment variable.
Exactly why it was becoming a non-issue. Default configs were fine.
Users, who didn't know any better, were routinely screwing around with this environment variable. And this could break your application programs.
Not at our job. Users were users who didn't know and didn't care. If something broke, someone fixed it for them and they were none the wiser.
As for whether the default was 3, or 8? It was ridiculously low.
For DOS, having 8 files open at the same time is really a pretty wild concept. Again, I was a developer and had never hit it (our project wasn't very complex, as I recall - 1 database and 3ish indexes).
And if I am ever going to lead a team doing MS-DOS development I'll be sure to bone up on the exact value.
And there we differ again - if I'm ever going to be lead on a team doing MS-DOS development, I'll be sure to tell them where they can stick their job
The answer is "3". The environment variable was NFILES.
:-)
Given that another followup says you got the number wrong, and
Frankly, I think it is a pretty reasonable question.
I don't think I'll be working for you
Really, if it'd been a sysadmin job, I might agree with you. But what it boils down to is that it's a trivia question; the answer is in some book, and I just shouldn't need to care. Windows was rolling along anyway, and soon enough it wouldn't matter at all.
If he'd asked "what's recursion?", or "how would you implement a sort?", or "how do you debug memory issues?", that would have been appropriate.
It turns out I'm a good programmer, and I program in Java (most of the time, these days), but I can't remember how to write a main() method. What I do know is that if I fire up my copy of emacs and type 'main ', it will expand and fill in all the right trivia because I looked it up once and made sure I'd never have to remember again.