What you're describing is illegal, and we WERE discussing legal identification.
This isn't new, it's just happening on planes to white people. You are about 100 years too late to stop it.
No, it isn't. White folks are not arbitrarily being ID'd, nor are any particular folks. You might argue that it is all arbitary, but EVERYONE is being ID'd because those are the rules.
Don't confuse racism with rules put in place to protect against [law suits for plane crashes, scalped tickets, security, whatever]. You belittle the problems of racism and cloud the [non-]issue at hand.
Gotta disagree with you. It has nothing to do with freedom. If you want to travel anonymously, take the bus or train or walk or ride a bike - nobody is stopping you.
The "freedom to take a plane without showing ID" is arbitrary and has little or nothing to do with freedom.
Don't believe Apple. They tell you anything to sell a computer. It's not a UNIX either, you have to be certified to be a UNIX. Something Apple never got around to, maybe because they are not compatible enough.
Ya know, I thought it was Unix(tm) certified, but I can't find anything that actually says it is. They sure do put Unix on the box, though. 'Course, I can't seem to find anything that says Solaris is Unix certified, either.
As for saying anything to get me to buy a mac, I buy macs because I can do whatever I want. As for not compatible enough, I can run anything I want to on it.
I used to think that too but I have changed my mind. If there was nothing magical about perl then all languages would have a centralized library of objects and a easy way to download and install them (including dependency resolving). I agree with you that all languages should have this none of them do and there must be a reason for it.
I believe that the only reasons are: 1. It was the first good scripting language (tm) (yeah, folks will disagree with first, and good, but there ya go). 2. The folks at the top are really smart, and realize how important good libraries are. 3. The whole purpose of perl was to make things easier to do*
* This is an important driving force, and it shows up all over the place. Note: easier to DO, not maintain. It is easy to install CPAN modules, use them, etc. It turns out that maintaining them isn't as easy as installing them (or so I've found). There are reasons for this, I'm sure, but one of the big ones (I think) is that perl is mostly a write-only language (hard to read/maintain, and that wasn't a goal). Other languages that have come later (or even earlier) had other goals (be better than perl, be more OO, be names after a gemstone, whatever). The fact that perl is slacker-oriented is great, and CPAN is part of what makes it great for slackers. (and by slackers, I mostly mean sysadmins who have better things to do than mess around with scripting language libraries, and I include myself amoung those).
This kind of thing is Ideal for java right?
Yup. SUN sucks. (yeah, folks will disagree with that, but there ya go)
Unless a language is object oriented and supports reflection [someobject.findMethodNamed("someMethod").execute( )], and some form of GC (though I don't require it be automated, so that is largely a library issue), I won't bother learning it.
That doesn't go for scripting languages (as far as I'm concerned), which I don't generally feel are appropriate for large projects.
install Whatever::Whatnot" and have it in under 5 minutes
There is nothing magic about perl that makes this work. There is something magic about the maintainers and founders (I have the utmost respect for Mr. Wall) that makes this work. Java's webstart is SUN's half-baked attempt at this kinda thing. The PHP folks should do this - as should all the other scripting languages. Hell, all the other languages should do this kinda thing as much as possible.
There is a hack that will allow you to convert anything going to your speakers to MP3. All you need is to stream that MP3 using some MP3->streaming music station and play that via itunes. Seems very hacky, but ought to work - depending on latency issues (if you also want to, for example, have it sync'd with DVD video).
And in fact it is a nightmare if you want to deploy it on multiple FBSD boxes - and heaven forbid you want to sell a product that depends on it and make clients install it.
After spending a good few hours understanding how to develop in this environment,I honestly think that the effort and pain needed to put together this simple currency converter app, is not worth it.... I could have done the same thing in any other environment (Swing/VB/ old Res-edit & Pascal), in minutes... What is the big deal surrounding MVC for a GUI?
As could I with xcode/IB.
Tell me, Can I make a dynamic screen, that adjusts itself based on the data inside it (AKA Java Swing)....
Sure.
What about creating reuseable, database linked components, that can be dropped into any screen in a line of code?
If you feel you need to write code to do that, you're doing something wrong. You should be able to drop something like that into your screen in ZERO lines of code.
Umm... where did you get this right, if I may ask?
If that's the company policy then sure, no problem, they have the right to do this.
But if you, a regular paid employee, decided that you know better which email should be delivered and which should not, who exactly gave you the authority to do that?
As I posted in another thread (you'll see, no doubt), it's my mailserver. I set it up, it's my hardware. Yeah, I have a few users, and they [have to] trust me. If I was running a company mailserver, I'd recommend doing the same thing (reject unauth MTA IP's).
You're right - it is a policy decision; my server, my policy.
Now, considering that well over 70% of the messages coming into my domains are spam, I have every right to reject mail that I believe is unwelcome.
I am sorry, where exactly did you get this right?
They set up a mailserver. That's all they need to get the rights to accept/reject. You don't like it, use someone else's mailserver. Nobody is forcing you to adapt SPF (or anything else). Nobody is forcing you to use a mailserver that does.
Let's say you're a doctor working in a hospital and it's winter, there is a lot of flu going around. Do you think you have a right to forcibly inject every person in the hospital with a flu vaccine regardless of whether they want it or not?
We're past the flu, and onto malaria. Yes, I have the right and responsibility to vaccinate everyone in my hospital. This is no conspiracy - don't like it, don't visit my hospital.
The job of a mailserver admin is NOT to decide who's allowed to send mail to the users and who's not. If a user asks (e.g. block all but this whitelist), sure. But absent a request from the user, you have no rights to decide which email goes through and which is blocked (with obvious exceptions for things like viruses).
You are a mailserver admin -- that's a SUPPORT position. You don't decide what your users are allowed to see and you have no rights to demand to know the real name of people who are not even your users, but are just sending email to them.
Totally disagree. I claim the right and responsibility to only deliver mail that was sent from an authorized MTA IP of the sender domain - which is what SPF does. If you wanna send as @yahoo.com, use their interface and mailserver (if they implement SPF), or get them to list your IP as an authorized sender. Either of those is a reasonable thing to do (enabling SMTPS seems like the best idea).
IF one of my users has a reasonable need to receive mail from a participating SPF domain that has a "rogue user" (sender from a non-authorized MTA IP), I'd consider labeling all incoming mail from non-authorized MTA's as suspect, and letting spam filters sort 'em out.
In the real world, the latter will be my initial implementation of SPF - until I trust it enough to just discard non-authorized MTA email.
The problem is, Sun is still good at doing one thing: Java
Woah.
<rant> Sun sucks ass at Java. A VM that can only run one program at a time? Come on - we've been making real machines that run multiple programs at the same time for a long time. Not compiling to machine-native? The AWT? Swing, even? The miserable failure of applets and that technology. Damn, the list goes on and on.
Don't get me wrong, I'm coding in Java in my other windows right now, but I avoid Sun's terrible libraries whenever I can. I don't think of Java as a product of Sun, but as a product of a few people who used to work at Sun. And Sun has been driving it into the dirt ever since.
The sooner they get paid off by IBM and/or Apple to set that language free, the happier I'll be. </rant>
What juridiction is this guy in? In my state, small claims court does not allow attorneys.
I'm thinking that you mean either attorneys are not allowed to sue using small claims court, or that the apple shareholders should have appeard as the defense. I don't think either of those is likely.
Someone has to speak for Apple. You didn't think it'd be Steve, did you? And if Apple has to send someone to plead their defense, who do you suppose Apple sends to court?
I would suspect that the plaintiff is not allowed to use an attorney in court. But even that I find dubious.
It seems to me that someone needs start the RFC process right now, describing a properly working, non-proprietary system. Otherwise, the Convicted Monopolist will once again do as described in the Halloween Documents.....
The open software community has kept bickering and their heads in the sand for too long. They should have jumped on something 5-10 years ago. Instead they stood around and argued things like SMTP's security flaw[s] don't really matter, and fixing them won't stop spam.
There HAVE been suggestions, patches, etc. It seems all the SMTP software folks have been hedging their bets waiting for the best one to make itself known. Meanwhile, Sendmail has offered nothing.
After YEARS of this being obvious, M$ is finally taking action. Fabulous, I say - at least the open source world will have something to conform to.
(note: I'm a big fan of open source and have contributed to many projects. I use open source. I believe in it. But [we] sure dropped the ball on this one.)
How are SPF or DomainKeys or SMTP AUTH going to help you when all your spam comes from people you know, because spammers have moved to just taking over machines and using those machines to spam the people that person normally emails, as that person?
In the unlikely event that someone I knew became an unwitting spam host, I'd inform them and have them fix their server. Why is that even a question?
SPF seems like such an easy, simple implementation, it's hard for me to understand why folks aren't jumping all over it. For example: I think that sendmail is NOT pushing this solution. My conspiracy theory for that is it's not an "email only" solution, and involves DNS, which sendmail has no finger in.
And this is the sort of response that drives people actually looking to learn UNIX away.
For the sarcastically impaired (you, at this point), I was kidding. That's what the smiley face is all about.
But to further the discussion: anyone who isn't willing to get their hands dirty pretty quick SHOULD avoid the commandline. After all, the commandline should not be needed for ANYTHING.
Especially on OS X.
The sooner the other *nixen realize that virtually all the books and effort put into making the commandline "easier" or "friendlier" would better be spend making nice GUI interfaces, the better off they'd be. "Learning Unix" should not require a commandline.
Slashdot Mirror
What you're describing is illegal, and we WERE discussing legal identification.
This isn't new, it's just happening on planes to white people. You are about 100 years too late to stop it.
No, it isn't. White folks are not arbitrarily being ID'd, nor are any particular folks. You might argue that it is all arbitary, but EVERYONE is being ID'd because those are the rules.
Don't confuse racism with rules put in place to protect against [law suits for plane crashes, scalped tickets, security, whatever]. You belittle the problems of racism and cloud the [non-]issue at hand.
You need a licence to have/do most things involving life and death. Like serving food, owning a gun, performing surgery, etc.
Your name is not on your licenseplate, however. Well, unless you had it personalized...
Nobody knows who you are when you're driving - and lest you suggest that the cops can look it up - they don't know if it is the owner driving.
So driving is pretty damn anonymous.
Gotta disagree with you. It has nothing to do with freedom. If you want to travel anonymously, take the bus or train or walk or ride a bike - nobody is stopping you.
The "freedom to take a plane without showing ID" is arbitrary and has little or nothing to do with freedom.
Don't believe Apple. They tell you anything to sell a computer. It's not a UNIX either, you have to be certified to be a UNIX. Something Apple never got around to, maybe because they are not compatible enough.
Ya know, I thought it was Unix(tm) certified, but I can't find anything that actually says it is. They sure do put Unix on the box, though. 'Course, I can't seem to find anything that says Solaris is Unix certified, either.
As for saying anything to get me to buy a mac, I buy macs because I can do whatever I want. As for not compatible enough, I can run anything I want to on it.
It entirely depends on the courses being taught.
If the school teaches UNIX courses, you need Linux machines for people to work on...
OK, I gotta laugh at that one. Since linux is not unix(tm), whereas OSX is unix.
Yeah, linux is unix enough/equivalent/whatever. But so is OSX.
I used to think that too but I have changed my mind. If there was nothing magical about perl then all languages would have a centralized library of objects and a easy way to download and install them (including dependency resolving). I agree with you that all languages should have this none of them do and there must be a reason for it.
I believe that the only reasons are:
1. It was the first good scripting language (tm)
(yeah, folks will disagree with first, and good, but there ya go).
2. The folks at the top are really smart, and realize how important good libraries are.
3. The whole purpose of perl was to make things easier to do*
* This is an important driving force, and it shows up all over the place. Note: easier to DO, not maintain. It is easy to install CPAN modules, use them, etc. It turns out that maintaining them isn't as easy as installing them (or so I've found). There are reasons for this, I'm sure, but one of the big ones (I think) is that perl is mostly a write-only language (hard to read/maintain, and that wasn't a goal). Other languages that have come later (or even earlier) had other goals (be better than perl, be more OO, be names after a gemstone, whatever). The fact that perl is slacker-oriented is great, and CPAN is part of what makes it great for slackers. (and by slackers, I mostly mean sysadmins who have better things to do than mess around with scripting language libraries, and I include myself amoung those).
This kind of thing is Ideal for java right?
Yup. SUN sucks.
(yeah, folks will disagree with that, but there ya go)
You know what language does not matter.
( )], and some form of GC (though I don't require it be automated, so that is largely a library issue), I won't bother learning it.
Gotta disagree with you, there.
Unless a language is object oriented and supports reflection [someobject.findMethodNamed("someMethod").execute
That doesn't go for scripting languages (as far as I'm concerned), which I don't generally feel are appropriate for large projects.
install Whatever::Whatnot" and have it in under 5 minutes
There is nothing magic about perl that makes this work. There is something magic about the maintainers and founders (I have the utmost respect for Mr. Wall) that makes this work. Java's webstart is SUN's half-baked attempt at this kinda thing. The PHP folks should do this - as should all the other scripting languages. Hell, all the other languages should do this kinda thing as much as possible.
Food for thought.
There is a hack that will allow you to convert anything going to your speakers to MP3. All you need is to stream that MP3 using some MP3->streaming music station and play that via itunes. Seems very hacky, but ought to work - depending on latency issues (if you also want to, for example, have it sync'd with DVD video).
And in fact it is a nightmare if you want to deploy it on multiple FBSD boxes - and heaven forbid you want to sell a product that depends on it and make clients install it.
Worst. Solution. Ever.
(granted, it is a solution, but it sure blows)
After spending a good few hours understanding how to develop in this environment,I honestly think that the effort and pain needed to put together this simple currency converter app, is not worth it.... I could have done the same thing in any other environment (Swing/VB/ old Res-edit & Pascal), in minutes... What is the big deal surrounding MVC for a GUI?
As could I with xcode/IB.
Tell me, Can I make a dynamic screen, that adjusts itself based on the data inside it (AKA Java Swing)....
Sure.
What about creating reuseable, database linked components, that can be dropped into any screen in a line of code?
If you feel you need to write code to do that, you're doing something wrong. You should be able to drop something like that into your screen in ZERO lines of code.
Umm... where did you get this right, if I may ask?
If that's the company policy then sure, no problem, they have the right to do this.
But if you, a regular paid employee, decided that you know better which email should be delivered and which should not, who exactly gave you the authority to do that?
As I posted in another thread (you'll see, no doubt), it's my mailserver. I set it up, it's my hardware. Yeah, I have a few users, and they [have to] trust me. If I was running a company mailserver, I'd recommend doing the same thing (reject unauth MTA IP's).
You're right - it is a policy decision; my server, my policy.
Now, considering that well over 70% of the messages coming into my domains are spam, I have every right to reject mail that I believe is unwelcome.
I am sorry, where exactly did you get this right?
They set up a mailserver. That's all they need to get the rights to accept/reject. You don't like it, use someone else's mailserver. Nobody is forcing you to adapt SPF (or anything else). Nobody is forcing you to use a mailserver that does.
Let's say you're a doctor working in a hospital and it's winter, there is a lot of flu going around. Do you think you have a right to forcibly inject every person in the hospital with a flu vaccine regardless of whether they want it or not?
We're past the flu, and onto malaria. Yes, I have the right and responsibility to vaccinate everyone in my hospital. This is no conspiracy - don't like it, don't visit my hospital.
The job of a mailserver admin is NOT to decide who's allowed to send mail to the users and who's not. If a user asks (e.g. block all but this whitelist), sure. But absent a request from the user, you have no rights to decide which email goes through and which is blocked (with obvious exceptions for things like viruses).
You are a mailserver admin -- that's a SUPPORT position. You don't decide what your users are allowed to see and you have no rights to demand to know the real name of people who are not even your users, but are just sending email to them.
Totally disagree. I claim the right and responsibility to only deliver mail that was sent from an authorized MTA IP of the sender domain - which is what SPF does. If you wanna send as @yahoo.com, use their interface and mailserver (if they implement SPF), or get them to list your IP as an authorized sender. Either of those is a reasonable thing to do (enabling SMTPS seems like the best idea).
IF one of my users has a reasonable need to receive mail from a participating SPF domain that has a "rogue user" (sender from a non-authorized MTA IP), I'd consider labeling all incoming mail from non-authorized MTA's as suspect, and letting spam filters sort 'em out.
In the real world, the latter will be my initial implementation of SPF - until I trust it enough to just discard non-authorized MTA email.
Succintly put.
Bravo.
Did you ever try to run Java on Os X?
It is my preferred dev environment.
I have jedit and a webobjects app running as I type.
I think the worst part is that it looks similar but is very inferior.
And for that, I blame Sun - not Apple. Cocoa absolutely rocks, and I wouldn't use Java at all if Cocoa had real GC (and WebObjects/EOF).
The problem is, Sun is still good at doing one thing: Java
Woah.
<rant>
Sun sucks ass at Java. A VM that can only run one program at a time? Come on - we've been making real machines that run multiple programs at the same time for a long time. Not compiling to machine-native? The AWT? Swing, even? The miserable failure of applets and that technology. Damn, the list goes on and on.
Don't get me wrong, I'm coding in Java in my other windows right now, but I avoid Sun's terrible libraries whenever I can. I don't think of Java as a product of Sun, but as a product of a few people who used to work at Sun. And Sun has been driving it into the dirt ever since.
The sooner they get paid off by IBM and/or Apple to set that language free, the happier I'll be.
</rant>
That's a HUGE number. How can you look at this as anything less than a tremendous market for high speed connections?
How many high speed connection folks are willing to downgrade?
If I were a dialup only provider, I'd be terrified.
Funny, I was just the opposite. I slugged my way through Crypto, but found Quicksilver to be an easier read.
Results?
What juridiction is this guy in? In my state, small claims court does not allow attorneys.
I'm thinking that you mean either attorneys are not allowed to sue using small claims court, or that the apple shareholders should have appeard as the defense. I don't think either of those is likely.
Someone has to speak for Apple. You didn't think it'd be Steve, did you? And if Apple has to send someone to plead their defense, who do you suppose Apple sends to court?
I would suspect that the plaintiff is not allowed to use an attorney in court. But even that I find dubious.
It seems to me that someone needs start the RFC process right now, describing a properly working, non-proprietary system. Otherwise, the Convicted Monopolist will once again do as described in the Halloween Documents.....
The open software community has kept bickering and their heads in the sand for too long. They should have jumped on something 5-10 years ago. Instead they stood around and argued things like SMTP's security flaw[s] don't really matter, and fixing them won't stop spam.
There HAVE been suggestions, patches, etc. It seems all the SMTP software folks have been hedging their bets waiting for the best one to make itself known. Meanwhile, Sendmail has offered nothing.
After YEARS of this being obvious, M$ is finally taking action. Fabulous, I say - at least the open source world will have something to conform to.
(note: I'm a big fan of open source and have contributed to many projects. I use open source. I believe in it. But [we] sure dropped the ball on this one.)
How are SPF or DomainKeys or SMTP AUTH going to help you when all your spam comes from people you know, because spammers have moved to just taking over machines and using those machines to spam the people that person normally emails, as that person?
In the unlikely event that someone I knew became an unwitting spam host, I'd inform them and have them fix their server. Why is that even a question?
SPF seems like such an easy, simple implementation, it's hard for me to understand why folks aren't jumping all over it. For example: I think that sendmail is NOT pushing this solution. My conspiracy theory for that is it's not an "email only" solution, and involves DNS, which sendmail has no finger in.
And this is the sort of response that drives people actually looking to learn UNIX away.
For the sarcastically impaired (you, at this point), I was kidding. That's what the smiley face is all about.
But to further the discussion: anyone who isn't willing to get their hands dirty pretty quick SHOULD avoid the commandline. After all, the commandline should not be needed for ANYTHING.
Especially on OS X.
The sooner the other *nixen realize that virtually all the books and effort put into making the commandline "easier" or "friendlier" would better be spend making nice GUI interfaces, the better off they'd be. "Learning Unix" should not require a commandline.
Can you recommend a good book that explains its contents to me?
:-)
Man formats and displays the on-line manual pages.
If that looks familiar, it's because it's the first line of the man page.
If you're still lost, I recommend you avoid the commanline