Karen Sandler of the GNOME Foundation (and Software Freedom Law Center) called attention to this exact problem in 2010 after she had a Medtronic defibrillator installed.
Sending, really? What, down a modem, via email, on a webpage?
Reporter Sam Varghese did slightly misstate things in that sentence, but then quoted me a couple of sentences later with the full picture:
Remember the 'Pentium Processor Invalid Instruction Erratum' of 1997, exposing all Intel Pentium and Pentium MMX CPUs to remote security attack, stopping them in their tracks if they could be induced to run processor instruction 'F0 0F C7 C8'?
You know, reading with context with improve your life. Give it a try: Even Slashdot pseuds can summon up the attention span, on a good day.
Ah, nostalgia: I made fun of all of those, and some several dozen others, about a month ago. Except dar.b and HackTool.Linux.BF, which appear to be known only to Kaspersky: Post actual information about those, and I'll be glad to mock them, too.
Can we stop giving a soapbox to a man who claims to channel Pan?
Hypothetically, if I ever claimed, while waxing poetic, that Clio (muse of history) had reached out of my hindbrain, thundered "YOU!", and helped me write really gripping and compelling historical essays, presumably you'd want everyone to cease paying attention to everything I say. (So much for metaphor.)
OK, but why should we pay attention to you, when obviously you're trying to convince the world you're possessed by Thalia the muse of comedy?
I agree that retransmitting someone else's message to a new recipient will be seriously problematic in SPF land and will break ".forward" files all over the world.
Until a millisecond after the user replaces
user@domain.tld
...in his.forward file with...
|/usr/bin/srs user@domain.tld
...and the sysadmin inserts these two lines into/etc/aliases (after installing Mail::SRS from CPAN):
non-RAID. Their Web site pages where the binary-only proprietary drivers are available make clear that it's a type of manufacturer-specific software RAID that they call "nvRAID". I've just recently added that information and relevant links to my Serial ATA on Linux page.
Bah, all I want is the installer kernel to be able to grok my SATA RAID set, without having to resort to custom boot disks, or God forbid, using Debian or Gentoo. When will a mainstream, it-just-works distro support these disk controllers?
Linux block device support depends on which particular SATA chipset you have -- you didn't identify yours -- and on what version of installation kernel the Linux distribution uses.
Why? Because some some chipsets (3Ware 8xxx, Adaptec AAR 24x0, LSI Logic MegaRAID SATA 150-4/150-6) work just fine using drivers developed for their PATA predecessor chipsets, some chipsets require either a 2.6.x kernel or a very recent 2.4.x one, a few chipsets (such as HP SA5xxx) require some vintage of 2.6.x kernel, and some very new ones (e.g., Marvell Technology Group Ltd. 88SX6081, 88SX6041, and 88SX5080) don't yet have drivers.
And then there's the matter of your "RAID set": You might be referring to some SATA RAID card manufacturer's proprietary software RAID, e.g., Promise, Highpoint, VIA), which is going to (1) be basically terrible, and (2) require some god-awful proprietary, binary-only driver, which I doubt you're going to find without resorting to the "custom boot disks" you speak of. Much smarter (unless you're tied to such hideous fakeraid solutions by a need to dual-boot MS-Windows) would be blow away the array and use Linux's "md" software RAID support, which is faster, is more robust, and won't require you to buy the same host adapter a second time if the first one dies, or lose all your data.
If your "SATA RAID set" happens to be on a Silicon Image 311x host adapter, then you're (potentially) in luck, because Thomas Horsten figured out the "Medley" software RAID format and wrote a "medley" subdriver for the ataraid mid-level driver, which is available in kernel 2.4.26 and later.
I cover all of these matters on a Web page where I try to track Linux SATA support as it develops. See "Serial ATA" in my knowledgebase's hardware category.
In summary, IBM's JDK is Sun's JDK. There is no competing clean-room JDK out there I know of except Kaffe (and TowerJ?).
On Linux, we have the following JREs:
Japhar
Kaffe
SableVM (JVM only; add SablePath class libs for a JRE)
KissMe (JVM only; add GNU Classpath for a JRE)
gcj's JRE (but that's actually just the Kaffe JVM + GNU Classpath, relabelled)
JanosVM (JVM only; derived from Kaffe)
On Solaris/SPARC, there's LaTTe.
I imagine the flies in the ointment with all of these are that they lag behind Sun's implementations, and that their class libraries haven't yet developed the enormous breadth of functionality that the proprietary-leaning Java developer world has come to rely on for most Java apps.
Consider, for example, the many MUAs coded in Java, e.g., Columba, flap, fruMailer, Grendel, ICEMail, JMail, PolarBar Mailer, YAMM, ayumail, DART Mail, ENIP, jamail, PonyEspresso, spaces, and ZOE: Many of these were produced by leveraging the functionality built into Sun's core classlibs, Sun Javamail class library, JavaBeans Activation Framework, Java XML classes, and other such things. Making those work on Kaffe + GNU Classpath is likely to remain infeasible for quite some time, for lack of equivalents to those proprietary facilities.
As I understand it, in general, the problem for open-source fans isn't that one can't write open-source Java -- one can -- but rather that most of the Java written (irrespective of that code's own licensing) cannot run using the facilities so far available in open-source runtime environments, because of considerations like those I've detailed.
And, of course, that bothers some people a lot more than others.;-)
Which does not help the person who runs a pure testing machine.
As the old punchline goes, "Well, don't do that, then." There's nothing to lose from ensuring one is capable of specifying "-t unstable", and a great deal of utility potentially available from doing so.
Having said that, I do the same now.
Et voila, you're making my point for me.
However, that still doesn't help when, for example, KDE 3.1 (I believe 3.0 never made it) takes an exceptionally long time to just make it to unstable (as XFree86 4.3.0 is now doing).
This might be a problem for people who insist on seeing "KDE" as a single thing to be installed or not, as opposed to a collection of variously desirable and undesirable packages. It's difficult for me to empathise with such creatures, but admittedly they do exist.
As well, despite what some may say, unstable is aptly named.
Well, no. Now, you're resorting to overbroad handwaves. And, frankly, you know better. (Very likely, you're arguing for the sake of arguing.) There is never any significant guarantee of quality from unstable-branch packages other than their building on the maintainer's system; but, then, there's no significant guarantee for testing-branch packages, either. All you gain on the latter branch is the rather thin protection of the automated testing-branch quarantining scripts.
To pick an example, any i386-arch user on the testing branch, some months ago, who declined to do the "-t unstable" trick for early access to openoffice.org 1.1 packages -- on no better grounds than being afraid of "unstable packages" -- would have been foolish, indeed.
There is not a single person who will give you sympathy if you hose your system by pulling in something from unstable.
Unfortunately for your argument, the same applies to testing.
Is it really too much to expect well known, much used, desktop packages to make it to testing in a timely manner?
This question suggests either 1. You're aware of how the quarantining scripts work, and are electing to ignore that knowledge, or 2. You're ignoring readily available sources of information on the subject. Multiple such resources, in fact.
Now, if you're proposing to lauch and run an additional functional branch (alongside stable, testing, unstable, and experimental) to meet your goals, by all means please do. Given the package pools system, it can be accomodated without increasing the load on mirror sites at all.
But if you're trying to make testing be something other than what its design goal is, then I suggest starting by reading the design documentation, first -- and then make a case for it on debian-devel.
Evolution is not even to be found in testing now, and for the longest while it was stuck at 1.0.8.
Technically true, but...
guido:~# apt-get -t unstable install evolution Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: gtkhtml3.0 libgal2.0-5 libgal2.0-common libgnome-pilot2 libgssapi1-heimdal libgtkhtml3.0-2 libpisync0 libsoup2.0-0 Suggested packages: gnome-pilot The following packages will be REMOVED: libgal2-0 libgal2-0-data The following NEW packages will be installed: evolution gtkhtml3.0 libgal2.0-5 libgal2.0-common libgnome-pilot2 libgssapi1-heimdal libgtkhtml3.0-2 libpisync0 libsoup2.0-0 0 upgraded, 9 newly installed, 2 to remove and 9 not upgraded. Need to get 11.7MB of archives. After unpacking 34.1MB of additional disk space will be used. Do you want to continue? [Y/n] n Abort. guido:~# cat/etc/apt/apt.conf APT::Default-Release "testing"; guido:~#
That looks to be v. 1.4.5.
Between the packages available in testing and those available by typing "apt-get -t unstable install [name]", I just don't seem to encounter the problems you cite. Of course, having to pull XFree86 4.3.0 from "experimental" would have been annoying for those incautious enough to buy video chipsets needing it, but I managed to avoid that.
Can I deinstall Exim and still have a functioning Apache server that I can log into and access the logs on the same box?
The literal answer to your question is "Yes, you can alternatively install any other package that supplies mail-transport-agent, and it will still work fine." But that doesn't address the substance of your objection, which is that any MTA will, if installed to provide that functionality, listen on port 25, and potentially be attackable.
Well, strictly speaking, not even quite that: Packages nullmailer and ssmtp both also qualify (hands off all locally generated mail to a smarthost of your choosing) -- but that would entail delivery off-system.
So, the substance of your complaint is that Debian's default Exim installation listens on all network interfaces, even if you set it up for local mail delivery only. That's a valid but very minor complaint (and I plan to suggest through the Debian BTS that/etc/exim/exim.conf say "local_interfaces = 127.0.0.1" in such cases). But even aside from exim's good security history, that's a pretty farfetched attack mode, since that daemon would be running with only the authority of user "mail". (Exim drops privilege.) It's pretty tough to do much with that.
Now, if you'd said "It's too darned easy to end up with the RPC portmapper installed and running by default", I'd have considered that a stronger position. The remedy of course is to check running daemons soonest, and disable (and preferably remove) anything you aren't sure you need -- same as on any other *ix.
Meanwhile (on your broader point), I consider the Debian attitude of "If you didn't want it exposed, don't turn it on" to be infinitely more cheering than that "Don't worry about being security-competent; the holy firewall will protect you" one prevalent elsewhere. And a filter set ("firewall") is as close as an "apt-get install" of easyfw, firehol, firestarter, firewall-easy, fwbuilder, gfcc, gnome-lokkit, guarddog, knetfilter, mason, etc.
I'm normally fairly confident in my ability to get Debian running on various hardware, but on some new Dell PowerEdge 1750s, I couldn't get the RAID controller to be recognized, because I couldn't find a Debian installer with a new enough kernel image.
Steve Mickeler's netinst image for Debian 3.0 "woody" would have done the trick for you. That and other specialised installers for Debian are detailed on my Debian installers page.
Yes, Knoppix (or Gnoppix, MEPIS, etc.) is a quite decent solution, and a leading one for some hardware situations (e.g., some SATA chipsets). It has the minor disadvantage of not being 100% Debian-compatible, e.g., its use of a/etc/sysconfig tree for networking.
Anyone seriously interested: Please read Linux Gazette's answering of pretty much all questions raised here, and correcting quite a few few misconceptions. E.g.:
We didn't "leave because we don't like CMSs" (Phil Hughes's claim)
It wasn't "some of the volunteers" (Phil Hughes's claim) but rather 100% of the staff by unanimous decision
We didn't spring the decision to move on SSC by surprise at the last minute (Phil Hughes's claim), but rather had warned them for months about what would happen if they went ahead with their plan.
The editors moved LG to new quarters in part because SSC had said the monthly magazine would cease to exist entirely. (We had no idea SSC would change its mind later and direct uncredited SSC employees to resume producing issues at our old site.) I.e., we actually don't think it's OK to "open up a new site under exactly the same name, even using the same logo", nor were we starting "a spinoff under the same name"; it was a question of move the magazine or let SSC kill the magazine by corporate decree, according to everything they'd told us.
Founder John M. Fisk, in 1996, transferred custody LG to SSC explicitly as a free magazine to be run in harmony with SSC's commercial magazine, Linux Journal. It was explicitly not to be a commercial property.
You cannot "own a name": You can own a commercial brand identity, but Linux Gazette has never been a commercial offering. SSC's assertion to the contrary in its USPTO filing is materially false.
Ownership of everything in LG is retained by each individual contributor, and issued to the public under an open-source licence -- just like with the Linux kernel
Even successful assertion of a trademark that you prove you own lets you enjoin only competing commercial goods or services using your mark in ways likely to confuse your customers into thinking those are your offerings. SSC's attempt to misuse trademark law -- in which they showed no interest for seven years until the very day we told them we were moving the magazine -- against our volunteer magazine seems to assume we're clueless techies and ignorant of trademark law fundamentals.
Discussion of the matter has been occurring at LWN. Here are my two recent posts:
"Chilling Effects" letter received from SSC, Inc.
(Posted Dec 5, 2003 9:05 UTC (Fri) by rickmoen) (Post reply)
Alan Cox wrote:
John Fisk founded Linux Gazette in 1995. He's not visibly part of either side of the argument which begs the question who did he give it to.
It's a fair question, and the top-level answer is that copyright over all content belongs to the individual authors, being published by each of them under an open-source licence (in LG's case, OPL v. 1.0, and two predecessor open-source licences for very early issues). Alan's no doubt very familiar with this concept. {grin}
Alan is of course thinking of some concept of ownership over the magazine as a whole, and that too is a fair question: The answer is that there's really nothing of that sort to own. The compilation copyright (if any) would likewise be OPL-licensed, and LG was from its inception explicitly a community, non-profit effort.
And that leaves an equally fair third question: What was it that John M. Fisk entrusted to SSC, Inc. -- subject to the promise to keep it non-commercial -- when medical school was keeping him too busy to keep things going? Please read again what John wrote: Phil Hughes and SSC, Inc. willingly assumed (and carried out admirably for many years) an obligation, a volunteer job, a custodianship.
And explicitly not over a corporate balance sheet asset, a lesson that Mr. Hughes seems to have f
Wolfrider wrote:
SSC should be BITCHslapped for trying to Bogart LG's body of work and the Whole Enchilada.
Feel welcome to bitchslap them.
The other shoe has just dropped: SSC evidently feels its easier and cheaper to try to seize our domain than to file a trademark-infringement lawsuit, and they've just delivered a cease & desist letter to our domain registrar, citing their bogus trademark claim. We are of course not sitting down for that, and are drafting a response just in case SSC causes the ICANN UDRP to be applied (as may be their intent). You can see a recent version of that draft at http://www.linuxgazette.com/node/view/134/228#228 (unless SSC deletes the post).
And, yes, we have indeed posted the demand letter to the EFF's http://www.chillingeffects.org/ Web site. It'll be case #983, when available for display, there.
The registration date is October 28, 2003, even though Linus Gazette has been publishing since '95. Sounds like SSC decided to register the trademark only when they realized they had a problem. That registration might be succeptible to challenge.
Or everyone could just let SSC, Inc. buy their $300 10-year (alleged) limited monopoly over a commercial brand identity (service mark), and just keep publishing Linux Gazette, because the one doesn't have a lot to do with the other.
Our non-commercial monthly community magazine (Linux Gazette) moved by unanimous decision of its staff to http://linuxgazette.net/ as of the November 2003 issue. For seven of the preceding eight years, SSC, Inc. was kind enough to assist LG by giving it hosting and allowing some of its staff to assist production during work hours, for which we are quite grateful.
Our decision to move was motivated by a number of things, including SSC's unexplained, unannounced, retroactive deletions from prior issues' articles, its stripping of authors' copyright notices and substitution of their own corporate one, and its proclaimed plans to make LG cease being a magazine and cease having editors, turning it into solely a dynamic Web site.
After our move of the magazine to new quarters, SSC to our astonishment produced a November issue purporting to be Linux Gazette, immediately after our November issue went to press. (This was surprising because we'd been told they intended that monthly magazine issues cease.)
To our further surprise, SSC, Inc. suddenly asserted posted "TM" symbols next to its copies of our magazine's logo, and started asserting in public that it owned trademark over the magazine "brand" identity. This was surprising because (1) SSC didn't start SSC, (2) SSC's assistance of founder John M. Fisk was specifically so that LG could remain a non-commercial community magazine, and (3) trademark is a commercial property right.
We were further surprised to learn that SSC, the day following our notifying SSC of our departure, filed a US $300 fee and application form with the USA Patent and Trademark Office asking for recognition of "Linux Gazette" as a service mark of SSC, Inc., asserting they made first use of it in commerce in 1996. This was surprising for a number of reasons: (1) The magazine was founded in 1995, not 1996 (by John M. Fisk, not SSC). (2) To our knowledge, the "mark" has never been used in commerce (and the whole idea of SSC helping was to keep the magazine non-commercial). (3) The correct symbol to use to claim a service mark (the term for brand insignia of commercial services as opposed to commercial goods) is "SM", not "TM".
Our understanding of trademark law is that, if the court judges a trade/service mark to be legitimately your property (which seems unlikely in this case) and if it's held to be validly established in commerce (ditto), then you're empowered to enjoin competing commercial interests from using that mark to sell a competing product/service, within the same trade/industry segment, in any way likely to confuse
customers into thinking you (rather than the competitor) produced or endorsed it. The alleged owner is obliged to enforce this claim through civil litigation (or risk losing the mark, through it becoming generic). Federal registration of a claimed mark gives broader geographical coverage of this right.
Please note that LG (at linuxgazette.net) remains a completely non-commercial magazine, which would appear to put its operations outside the normal scope of trademark law (leaving aside questions of validity and ownership). So far, we've received no legal threat from SSC, Inc., which is gratifying -- and we're concentrating on continuing to publish the magazine as we have for eight years. The December issue -- with a CSS stylesheet facelife and nicer logo -- will appear in a few days. As always, we're delighted
Fast-forward to 2003... The products are orphaned. They have been removed from the Corel Web site without a trace.
It's certainly true that they've been orphaned, but WP8 for Linux Download Personal Edition remains available at a large number of sites, listed in my WordPerfect for Linux FAQ. You can also find PhotoPaint9 (Winelib) tarballs, here and there, if so interested.
The open-source linux.corel.com site that contained Corel's WINE tree is gone.
And no service packs for the Linux versions of these programs ever got released!
Torrie's third-party updates to Corelwine, the Fontastic server, and other support code are said to make WP9 for Linux almost acceptable, although I find WP8 generally superior in fundamental ways. Valentijn Sessink has contributed a third-party fix to the Filtrix date-rollover problem, and there are numerous Corel-issued fixes to little bugs at http://corellinux.com/.
Your point generally is well taken: The corellinux.com site even enshrines Corel's lastingly broken promise to post an "Update coming soon for Corel WordPerfect 8 for Linux/UNIX import/export filter issue", which failure Sessink eventually worked around for the user community's benefit without Corel's help. However, I just wanted to point out that many problems can be fixed to a significant degree, despite Corel having cast the entire thing to the winds.
Library-support problems for WP8.x on modern Linux distributions can be fixed, given varying amounts of determination. In extreme cases, you can install all needed libs from a tarball available for that purpose. My FAQ has details.
I suspect you'd find WP8.x much less frustrating than the lamentable WP9, especially if you acquire a copy of the WP8.1 Personal Edition -- the best release by far of WP for Linux -- still sometimes available (on eBay and other places) bundled as part of Corel Linux OS Standard or Deluxe Editions.
But the long term answer is to realise that proprietary codebases are prone to being here today, gone tomorrow, and to realise that AbiWord 1.9.1 is starting to look awfully good and cannot suffer that same fate. (OpenOffice.org Writer 1.1 beta 2 is useful, too.)
Rick Moen
rick@linuxmafia.com
Esys / Execmail
on
Opengroupware
·
· Score: 3, Informative
gi-tux wrote:
EMail was based on IMAP, SMTP, and IMSP and came from a company then known as Esys, later ExecMail, not sure if they even exist anymore).
Originally it was called "Simeon" (MUA and MTA pieces), from Canadian firm Esys. Then it was Execmail from Execmail, Inc. Then, there were some mergers involving companies called Isode and Messaging Direct, Inc. (one of which may now own the other; I forget).
In any event, that firm now owns the rights, and could resell it if it wished, but has apparently discontinued the product, as they're no longer in that business.
I did a few minutes of research, and answered my own question: Client access to MS-Exchange Server's optional Microsoft Outlook Web Access connector (gateway) should work from basically any Web browser supporting frames and Javascript.
(I've amended the entry for MS-Exchange at http://linuxmafia.com/~rick/linux-info/groupware accordingly -- along with fixing errors or omissions in the entries for Kroupware, Novell Groupwise, SuSE Openexchange Server, and EasyGate Workgroup.)
Webmail in the Exchange world is Outlook Web Access (OWA). Very easy to install and get running. It provides virtually all of the same functionality as Outlook, including calendar access, etc.
Thanks for commenting. I vaguely recall hearing that client Web access works properly only from MSIE, but have had no opportunity to investigate, for lack of either MS-Windows or MS-Exchange Server. Any clarification would be welcome.
Another note about Exchange. Everyone wants calendar sharing, but if you ask them if they are using it they usually say no.
The main exceptions are VPs/division heads/CEOs, who want their secretaries to be able to manage their schedules for them. And guess what? They're precisely the ones who approve IT deployments.
There tends to be confusion in these discussions because of lack of agreement on what the term "Exchange replacement" means. At one extreme, something qualfies only if it accepts Microsoft-proprietary RPC connections from MS-Outlook for MAPI transactions providing 100% of the functions the Outlook / Exchange Server combination du jour supports. At the other extreme, Web-based access (e.g., Sherpath) and glorified BBSes (First Class, Citadel/UX) are deemed worthy of consideration.
Anyhow, here's a list I maintain as part of http://linuxmafia.com/~rick/linux-info/groupware:
MS Exchange Server (server end; NT only), MS Outlook (client end; Win32, MacOS). Very limited support of open-protocol clients (IMAP, webmail?). Microsoft Corp. wants to sell you Exchange 2000, these days, but Exchange 5.5 is still very common.
Novell Groupwise. http://www.novell.com/products/groupwise/ Server end runs on either Novell NetWare 5/6 or WinNT. Client end is proprietary Win32 client or webmail. A native Linux client is under development.
SuSE Linux Openexchange Server (formerly SuSE Linux eMail Server). Standard, good open-source components (Postfix, Apache, Cyrus IMAP, OpenLDAP, OpenSSL) preconfigured to work well with one another, plus a couple of proprietary components: YaST2 for graphical administration, and SkyrixGreen for integrated scheduling and group discussions (shared folders). Client access from any OS, including but not limited to webmail. A full-functional trial version (lacking only "maintenance") is available for US $20 at http://www.suse.com/openexchange/slox_eval_form.ht ml . Sites are known to scale well to at least 1,000 users per site. The largest deployment yet known (March 2003) is 1,900 users.
Bynari Insight Server, http://www.bynari.net/ . Server end is Linux-based. Intended as a plug-compatible replacement for MS-Exchange Server, based on POP3, IMPA, SMTP, and LDAP, but also with full support for all the special, proprietary MS-Exchange Server RPC-based protocols for group discussion, scheduling, contact management, task lists, etc., when used with MS-Outlook clients. Review: http://linuxjournal.com/article.php?sid=6734
Bynari InsightConnector, http://www.bynari.net/ . Extensions that load into MS-Outlook clients to let them perform MS-Exchange-type functions (scheduling, contact-management, public folders) without needing an MS-Exchange server, using only open-standard IMAP, SMTP, and LDAP servers, instead.
Samsung Contact (formerly HP Openmail), http://samsungcontact.com/en/ . Server end can be Linux-based (or Solaris/AIX). Based on SMTP, IMAP, POP3, LDAP. Supports proprietary protocols for e-mail, scheduling, etc. native to Samsung's Contact client (which is available on Linux and Win32). Webmail access. Implements Microsoft's (documented, for a change) MAPI protocol for scheduling, public folders, offline folders.
Oracle Collaboration Suite, http://www.oracle.com/ip/deploy/cs/ . Formerly Steltor CorporateTime, http://www.steltor.com/, until that firm's recent acquisition by Oracle. (That product is said to have emerged from Netscape Calendar.) Does IMAP, POP3, SMTP, E-mail, real-time conferences, voicemail, scheduling. Apparently implements all of the special, proprietary MS-Exchange Server RPC-based protocols for group discussion, scheduling, contact management,
Check out the list of packages included with Red Hat Linux 9. You'll find exactly zero non-free software.
Only because you brought the subject up:
"pine 4.44 A commonly used, MIME compliant mail and news reader." This code is source-available, but licensed under proprietary terms (no right to fork).
In pointing out this inclusion of the proprietary pine/pico/pilot package, I intend no criticism of Red Hat Software, Inc., which does it for perfectly understandable reason, given the pine MUA's wide appeal and lack of an open-source replacement acceptable to that customer base that doesn't suffer the same copyright encumbrance (as MANA does). Chris Allegretta's "nano" has nicely eliminated the pico problem, but ditching pine itself without seriously ticking off a fair number of people remains difficult.
When I saw that Red Hat had (by the 8.0 release) reduced the number of proprietary packages to just this one -- having pushed the envelope in jettisoning the old proprietary Java packages, ditched Navigator/Communicator in favour of Mozilla and Acrobat Reader in favour of xpdf, and actually helped write a replacement for xv -- I was (and remain) quite impressed. They've shown impressive leadership, in this area.
But it remains a (small) factual error to claim that the distribution is 100% free / open-source software.
Slashdot Mirror
Karen Sandler of the GNOME Foundation (and Software Freedom Law Center) called attention to this exact problem in 2010 after she had a Medtronic defibrillator installed.
http://www.softwarefreedom.org...
https://www.youtube.com/watch?...
Sending, really? What, down a modem, via email, on a webpage?
Reporter Sam Varghese did slightly misstate things in that sentence, but then quoted me a couple of sentences later with the full picture:
You know, reading with context with improve your life. Give it a try: Even Slashdot pseuds can summon up the attention span, on a good day.
Rick Moen
rick@linuxmafia.com
I'm not sure I understand the point of this article.
Condolences. But if you ponder long and hard, you might spot the pattern
Rick Moen
rick@linuxmafia.com
Even better: Free Linux software...
[Same old lame list of toothless malware]
Ah, nostalgia: I made fun of all of those, and some several dozen others, about a month ago. Except dar.b and HackTool.Linux.BF, which appear to be known only to Kaspersky: Post actual information about those, and I'll be glad to mock them, too.
Rick Moen
rick@linuxmafia.com
Can we stop giving a soapbox to a man who claims to channel Pan?
Hypothetically, if I ever claimed, while waxing poetic, that Clio (muse of history) had reached out of my hindbrain, thundered "YOU!", and helped me write really gripping and compelling historical essays, presumably you'd want everyone to cease paying attention to everything I say. (So much for metaphor.)
OK, but why should we pay attention to you, when obviously you're trying to convince the world you're possessed by Thalia the muse of comedy?
Rick Moen
rick@linuxmafia.com
I agree that retransmitting someone else's message to a new recipient will be seriously problematic in SPF land and will break ".forward" files all over the world.
Until a millisecond after the user replaces
...in his .forward file with...
...and the sysadmin inserts these two lines into /etc/aliases (after installing Mail::SRS from CPAN):
It's documented. And amply so, too.
Rick Moen
rick@linuxmafia.com
nVidia: probably non-RAID (don't know for sure)
non-RAID. Their Web site pages where the binary-only proprietary drivers are available make clear that it's a type of manufacturer-specific software RAID that they call "nvRAID". I've just recently added that information and relevant links to my Serial ATA on Linux page.
Rick Moen
rick@linuxmafia.com
Bah, all I want is the installer kernel to be able to grok my SATA RAID set, without having to resort to custom boot disks, or God forbid, using Debian or Gentoo. When will a mainstream, it-just-works distro support these disk controllers?
Linux block device support depends on which particular SATA chipset you have -- you didn't identify yours -- and on what version of installation kernel the Linux distribution uses.
Why? Because some some chipsets (3Ware 8xxx, Adaptec AAR 24x0, LSI Logic MegaRAID SATA 150-4/150-6) work just fine using drivers developed for their PATA predecessor chipsets, some chipsets require either a 2.6.x kernel or a very recent 2.4.x one, a few chipsets (such as HP SA5xxx) require some vintage of 2.6.x kernel, and some very new ones (e.g., Marvell Technology Group Ltd. 88SX6081, 88SX6041, and 88SX5080) don't yet have drivers.
And then there's the matter of your "RAID set": You might be referring to some SATA RAID card manufacturer's proprietary software RAID, e.g., Promise, Highpoint, VIA), which is going to (1) be basically terrible, and (2) require some god-awful proprietary, binary-only driver, which I doubt you're going to find without resorting to the "custom boot disks" you speak of. Much smarter (unless you're tied to such hideous fakeraid solutions by a need to dual-boot MS-Windows) would be blow away the array and use Linux's "md" software RAID support, which is faster, is more robust, and won't require you to buy the same host adapter a second time if the first one dies, or lose all your data.
If your "SATA RAID set" happens to be on a Silicon Image 311x host adapter, then you're (potentially) in luck, because Thomas Horsten figured out the "Medley" software RAID format and wrote a "medley" subdriver for the ataraid mid-level driver, which is available in kernel 2.4.26 and later.
I cover all of these matters on a Web page where I try to track Linux SATA support as it develops. See "Serial ATA" in my knowledgebase's hardware category.
Rick Moen
rick@linuxmafia.com
ciggieposeur wrote:
[A very enlightening explanation. At the end:]
In summary, IBM's JDK is Sun's JDK. There is no competing clean-room JDK out there I know of except Kaffe (and TowerJ?).
On Linux, we have the following JREs:
On Solaris/SPARC, there's LaTTe.
I imagine the flies in the ointment with all of these are that they lag behind Sun's implementations, and that their class libraries haven't yet developed the enormous breadth of functionality that the proprietary-leaning Java developer world has come to rely on for most Java apps.
Consider, for example, the many MUAs coded in Java, e.g., Columba, flap, fruMailer, Grendel, ICEMail, JMail, PolarBar Mailer, YAMM, ayumail, DART Mail, ENIP, jamail, PonyEspresso, spaces, and ZOE: Many of these were produced by leveraging the functionality built into Sun's core classlibs, Sun Javamail class library, JavaBeans Activation Framework, Java XML classes, and other such things. Making those work on Kaffe + GNU Classpath is likely to remain infeasible for quite some time, for lack of equivalents to those proprietary facilities.
As I understand it, in general, the problem for open-source fans isn't that one can't write open-source Java -- one can -- but rather that most of the Java written (irrespective of that code's own licensing) cannot run using the facilities so far available in open-source runtime environments, because of considerations like those I've detailed.
And, of course, that bothers some people a lot more than others. ;-)
Rick Moen
rick@linuxmafia.com
As the old punchline goes, "Well, don't do that, then." There's nothing to lose from ensuring one is capable of specifying "-t unstable", and a great deal of utility potentially available from doing so.
Et voila, you're making my point for me. This might be a problem for people who insist on seeing "KDE" as a single thing to be installed or not, as opposed to a collection of variously desirable and undesirable packages. It's difficult for me to empathise with such creatures, but admittedly they do exist.Well, no. Now, you're resorting to overbroad handwaves. And, frankly, you know better. (Very likely, you're arguing for the sake of arguing.) There is never any significant guarantee of quality from unstable-branch packages other than their building on the maintainer's system; but, then, there's no significant guarantee for testing-branch packages, either. All you gain on the latter branch is the rather thin protection of the automated testing-branch quarantining scripts.
To pick an example, any i386-arch user on the testing branch, some months ago, who declined to do the "-t unstable" trick for early access to openoffice.org 1.1 packages -- on no better grounds than being afraid of "unstable packages" -- would have been foolish, indeed.
Unfortunately for your argument, the same applies to testing. This question suggests either 1. You're aware of how the quarantining scripts work, and are electing to ignore that knowledge, or 2. You're ignoring readily available sources of information on the subject. Multiple such resources, in fact.Now, if you're proposing to lauch and run an additional functional branch (alongside stable, testing, unstable, and experimental) to meet your goals, by all means please do. Given the package pools system, it can be accomodated without increasing the load on mirror sites at all.
But if you're trying to make testing be something other than what its design goal is, then I suggest starting by reading the design documentation, first -- and then make a case for it on debian-devel.
Rick Moen
rick@linuxmafia.com
Technically true, but...
That looks to be v. 1.4.5.
Between the packages available in testing and those available by typing "apt-get -t unstable install [name]", I just don't seem to encounter the problems you cite. Of course, having to pull XFree86 4.3.0 from "experimental" would have been annoying for those incautious enough to buy video chipsets needing it, but I managed to avoid that.
Rick Moen
rick@linuxmafia.com
The literal answer to your question is "Yes, you can alternatively install any other package that supplies mail-transport-agent, and it will still work fine." But that doesn't address the substance of your objection, which is that any MTA will, if installed to provide that functionality, listen on port 25, and potentially be attackable.
Well, strictly speaking, not even quite that: Packages nullmailer and ssmtp both also qualify (hands off all locally generated mail to a smarthost of your choosing) -- but that would entail delivery off-system.
So, the substance of your complaint is that Debian's default Exim installation listens on all network interfaces, even if you set it up for local mail delivery only. That's a valid but very minor complaint (and I plan to suggest through the Debian BTS that /etc/exim/exim.conf say "local_interfaces = 127.0.0.1" in such cases). But even aside from exim's good security history, that's a pretty farfetched attack mode, since that daemon would be running with only the authority of user "mail". (Exim drops privilege.) It's pretty tough to do much with that.
Now, if you'd said "It's too darned easy to end up with the RPC portmapper installed and running by default", I'd have considered that a stronger position. The remedy of course is to check running daemons soonest, and disable (and preferably remove) anything you aren't sure you need -- same as on any other *ix.
Meanwhile (on your broader point), I consider the Debian attitude of "If you didn't want it exposed, don't turn it on" to be infinitely more cheering than that "Don't worry about being security-competent; the holy firewall will protect you" one prevalent elsewhere. And a filter set ("firewall") is as close as an "apt-get install" of easyfw, firehol, firestarter, firewall-easy, fwbuilder, gfcc, gnome-lokkit, guarddog, knetfilter, mason, etc.
Rick Moen
rick@linuxmafia.com
Steve Mickeler's netinst image for Debian 3.0 "woody" would have done the trick for you. That and other specialised installers for Debian are detailed on my Debian installers page.
Yes, Knoppix (or Gnoppix, MEPIS, etc.) is a quite decent solution, and a leading one for some hardware situations (e.g., some SATA chipsets). It has the minor disadvantage of not being 100% Debian-compatible, e.g., its use of a /etc/sysconfig tree for networking.
Rick Moen
rick@linuxmafia.com
We didn't "leave because we don't like CMSs" (Phil Hughes's claim)
It wasn't "some of the volunteers" (Phil Hughes's claim) but rather 100% of the staff by unanimous decision
We didn't spring the decision to move on SSC by surprise at the last minute (Phil Hughes's claim), but rather had warned them for months about what would happen if they went ahead with their plan.
The editors moved LG to new quarters in part because SSC had said the monthly magazine would cease to exist entirely. (We had no idea SSC would change its mind later and direct uncredited SSC employees to resume producing issues at our old site.) I.e., we actually don't think it's OK to "open up a new site under exactly the same name, even using the same logo", nor were we starting "a spinoff under the same name"; it was a question of move the magazine or let SSC kill the magazine by corporate decree, according to everything they'd told us.
Founder John M. Fisk, in 1996, transferred custody LG to SSC explicitly as a free magazine to be run in harmony with SSC's commercial magazine, Linux Journal. It was explicitly not to be a commercial property.
You cannot "own a name": You can own a commercial brand identity, but Linux Gazette has never been a commercial offering. SSC's assertion to the contrary in its USPTO filing is materially false.
Ownership of everything in LG is retained by each individual contributor, and issued to the public under an open-source licence -- just like with the Linux kernel
Even successful assertion of a trademark that you prove you own lets you enjoin only competing commercial goods or services using your mark in ways likely to confuse your customers into thinking those are your offerings. SSC's attempt to misuse trademark law -- in which they showed no interest for seven years until the very day we told them we were moving the magazine -- against our volunteer magazine seems to assume we're clueless techies and ignorant of trademark law fundamentals.
Discussion of the matter has been occurring at LWN. Here are my two recent posts:
"Chilling Effects" letter received from SSC, Inc.
(Posted Dec 5, 2003 9:05 UTC (Fri) by rickmoen) (Post reply)
Alan Cox wrote:
John Fisk founded Linux Gazette in 1995. He's not visibly part of either side of the argument which begs the question who did he give it to.
It's a fair question, and the top-level answer is that copyright over all content belongs to the individual authors, being published by each of them under an open-source licence (in LG's case, OPL v. 1.0, and two predecessor open-source licences for very early issues). Alan's no doubt very familiar with this concept. {grin}
Alan is of course thinking of some concept of ownership over the magazine as a whole, and that too is a fair question: The answer is that there's really nothing of that sort to own. The compilation copyright (if any) would likewise be OPL-licensed, and LG was from its inception explicitly a community, non-profit effort.
And that leaves an equally fair third question: What was it that John M. Fisk entrusted to SSC, Inc. -- subject to the promise to keep it non-commercial -- when medical school was keeping him too busy to keep things going? Please read again what John wrote: Phil Hughes and SSC, Inc. willingly assumed (and carried out admirably for many years) an obligation, a volunteer job, a custodianship.
And explicitly not over a corporate balance sheet asset, a lesson that Mr. Hughes seems to have f
Feel welcome to bitchslap them.
The other shoe has just dropped: SSC evidently feels its easier and cheaper to try to seize our domain than to file a trademark-infringement lawsuit, and they've just delivered a cease & desist letter to our domain registrar, citing their bogus trademark claim. We are of course not sitting down for that, and are drafting a response just in case SSC causes the ICANN UDRP to be applied (as may be their intent). You can see a recent version of that draft at http://www.linuxgazette.com/node/view/134/228#228 (unless SSC deletes the post).
And, yes, we have indeed posted the demand letter to the EFF's http://www.chillingeffects.org/ Web site. It'll be case #983, when available for display, there.
Rick Moen
Contributing Editor, Linux Gazette
The registration date is October 28, 2003, even though Linus Gazette has been publishing since '95. Sounds like SSC decided to register the trademark only when they realized they had a problem. That registration might be succeptible to challenge.
Or everyone could just let SSC, Inc. buy their $300 10-year (alleged) limited monopoly over a commercial brand identity (service mark), and just keep publishing Linux Gazette, because the one doesn't have a lot to do with the other.
Our non-commercial monthly community magazine (Linux Gazette) moved by unanimous decision of its staff to http://linuxgazette.net/ as of the November 2003 issue. For seven of the preceding eight years, SSC, Inc. was kind enough to assist LG by giving it hosting and allowing some of its staff to assist production during work hours, for which we are quite grateful.
Our decision to move was motivated by a number of things, including SSC's unexplained, unannounced, retroactive deletions from prior issues' articles, its stripping of authors' copyright notices and substitution of their own corporate one, and its proclaimed plans to make LG cease being a magazine and cease having editors, turning it into solely a dynamic Web site.
After our move of the magazine to new quarters, SSC to our astonishment produced a November issue purporting to be Linux Gazette, immediately after our November issue went to press. (This was surprising because we'd been told they intended that monthly magazine issues cease.)
To our further surprise, SSC, Inc. suddenly asserted posted "TM" symbols next to its copies of our magazine's logo, and started asserting in public that it owned trademark over the magazine "brand" identity. This was surprising because (1) SSC didn't start SSC, (2) SSC's assistance of founder John M. Fisk was specifically so that LG could remain a non-commercial community magazine, and (3) trademark is a commercial property right.
We were further surprised to learn that SSC, the day following our notifying SSC of our departure, filed a US $300 fee and application form with the USA Patent and Trademark Office asking for recognition of "Linux Gazette" as a service mark of SSC, Inc., asserting they made first use of it in commerce in 1996. This was surprising for a number of reasons: (1) The magazine was founded in 1995, not 1996 (by John M. Fisk, not SSC). (2) To our knowledge, the "mark" has never been used in commerce (and the whole idea of SSC helping was to keep the magazine non-commercial). (3) The correct symbol to use to claim a service mark (the term for brand insignia of commercial services as opposed to commercial goods) is "SM", not "TM".
Our understanding of trademark law is that, if the court judges a trade/service mark to be legitimately your property (which seems unlikely in this case) and if it's held to be validly established in commerce (ditto), then you're empowered to enjoin competing commercial interests from using that mark to sell a competing product/service, within the same trade/industry segment, in any way likely to confuse customers into thinking you (rather than the competitor) produced or endorsed it. The alleged owner is obliged to enforce this claim through civil litigation (or risk losing the mark, through it becoming generic). Federal registration of a claimed mark gives broader geographical coverage of this right.
Please note that LG (at linuxgazette.net) remains a completely non-commercial magazine, which would appear to put its operations outside the normal scope of trademark law (leaving aside questions of validity and ownership). So far, we've received no legal threat from SSC, Inc., which is gratifying -- and we're concentrating on continuing to publish the magazine as we have for eight years. The December issue -- with a CSS stylesheet facelife and nicer logo -- will appear in a few days. As always, we're delighted
While I certainly join Bruce in liking (and using) Debian, there's certainly absolutely nothing wrong with RPM-based options such as cAos and Fedora.
Not to mention that getting "Linux distributors to unite behind" any one thing is doomed, anyway.
Rick Moen
rick@linuxmafia.com
Fast-forward to 2003... The products are orphaned. They have been removed from the Corel Web site without a trace.
It's certainly true that they've been orphaned, but WP8 for Linux Download Personal Edition remains available at a large number of sites, listed in my WordPerfect for Linux FAQ. You can also find PhotoPaint9 (Winelib) tarballs, here and there, if so interested.
The open-source linux.corel.com site that contained Corel's WINE tree is gone.
Substantially all of the former linux.corel.com Web site remains mirrored on http://corellinux.com/. The Corelwine fork remains maintained, for now, by Michael Torrie at http://students.cs.byu.edu/~torriem/.
And no service packs for the Linux versions of these programs ever got released!
Torrie's third-party updates to Corelwine, the Fontastic server, and other support code are said to make WP9 for Linux almost acceptable, although I find WP8 generally superior in fundamental ways. Valentijn Sessink has contributed a third-party fix to the Filtrix date-rollover problem, and there are numerous Corel-issued fixes to little bugs at http://corellinux.com/.
Your point generally is well taken: The corellinux.com site even enshrines Corel's lastingly broken promise to post an "Update coming soon for Corel WordPerfect 8 for Linux/UNIX import/export filter issue", which failure Sessink eventually worked around for the user community's benefit without Corel's help. However, I just wanted to point out that many problems can be fixed to a significant degree, despite Corel having cast the entire thing to the winds.
Library-support problems for WP8.x on modern Linux distributions can be fixed, given varying amounts of determination. In extreme cases, you can install all needed libs from a tarball available for that purpose. My FAQ has details.
I suspect you'd find WP8.x much less frustrating than the lamentable WP9, especially if you acquire a copy of the WP8.1 Personal Edition -- the best release by far of WP for Linux -- still sometimes available (on eBay and other places) bundled as part of Corel Linux OS Standard or Deluxe Editions.
But the long term answer is to realise that proprietary codebases are prone to being here today, gone tomorrow, and to realise that AbiWord 1.9.1 is starting to look awfully good and cannot suffer that same fate. (OpenOffice.org Writer 1.1 beta 2 is useful, too.)
Rick Moen rick@linuxmafia.com
EMail was based on IMAP, SMTP, and IMSP and came from a company then known as Esys, later ExecMail, not sure if they even exist anymore).
Originally it was called "Simeon" (MUA and MTA pieces), from Canadian firm Esys. Then it was Execmail from Execmail, Inc. Then, there were some mergers involving companies called Isode and Messaging Direct, Inc. (one of which may now own the other; I forget).In any event, that firm now owns the rights, and could resell it if it wished, but has apparently discontinued the product, as they're no longer in that business.
Rick Moen
rick@linuxmafia.com
(I've amended the entry for MS-Exchange at http://linuxmafia.com/~rick/linux-info/groupware accordingly -- along with fixing errors or omissions in the entries for Kroupware, Novell Groupwise, SuSE Openexchange Server, and EasyGate Workgroup.)
Rick Moen
rick@linuxmafia.com
Webmail in the Exchange world is Outlook Web Access (OWA). Very easy to install and get running. It provides virtually all of the same functionality as Outlook, including calendar access, etc.
Thanks for commenting. I vaguely recall hearing that client Web access works properly only from MSIE, but have had no opportunity to investigate, for lack of either MS-Windows or MS-Exchange Server. Any clarification would be welcome.
Rick Moen
rick@linuxmafia.com
Another note about Exchange. Everyone wants calendar sharing, but if you ask them if they are using it they usually say no.
The main exceptions are VPs/division heads/CEOs, who want their secretaries to be able to manage their schedules for them. And guess what? They're precisely the ones who approve IT deployments.
Rick Moen
rick@linuxmafia.com
MS Exchange Server (server end; NT only), MS Outlook (client end; Win32, MacOS). Very limited support of open-protocol clients (IMAP, webmail?). Microsoft Corp. wants to sell you Exchange 2000, these days, but Exchange 5.5 is still very common.
Lotus Notes / Domino (server end, Linux supported), Lotus Notes (client end; Win32, MacOS). Limited webmail access (iNotes).
Novell Groupwise. http://www.novell.com/products/groupwise/ Server end runs on either Novell NetWare 5/6 or WinNT. Client end is proprietary Win32 client or webmail. A native Linux client is under development.
SuSE Linux Openexchange Server (formerly SuSE Linux eMail Server). Standard, good open-source components (Postfix, Apache, Cyrus IMAP, OpenLDAP, OpenSSL) preconfigured to work well with one another, plus a couple of proprietary components: YaST2 for graphical administration, and SkyrixGreen for integrated scheduling and group discussions (shared folders). Client access from any OS, including but not limited to webmail. A full-functional trial version (lacking only "maintenance") is available for US $20 at http://www.suse.com/openexchange/slox_eval_form.ht ml . Sites are known to scale well to at least 1,000 users per site. The largest deployment yet known (March 2003) is 1,900 users.
Bynari Insight Server, http://www.bynari.net/ . Server end is Linux-based. Intended as a plug-compatible replacement for MS-Exchange Server, based on POP3, IMPA, SMTP, and LDAP, but also with full support for all the special, proprietary MS-Exchange Server RPC-based protocols for group discussion, scheduling, contact management, task lists, etc., when used with MS-Outlook clients. Review: http://linuxjournal.com/article.php?sid=6734
Bynari InsightConnector, http://www.bynari.net/ . Extensions that load into MS-Outlook clients to let them perform MS-Exchange-type functions (scheduling, contact-management, public folders) without needing an MS-Exchange server, using only open-standard IMAP, SMTP, and LDAP servers, instead.
Samsung Contact (formerly HP Openmail), http://samsungcontact.com/en/ . Server end can be Linux-based (or Solaris/AIX). Based on SMTP, IMAP, POP3, LDAP. Supports proprietary protocols for e-mail, scheduling, etc. native to Samsung's Contact client (which is available on Linux and Win32). Webmail access. Implements Microsoft's (documented, for a change) MAPI protocol for scheduling, public folders, offline folders.
Oracle Collaboration Suite, http://www.oracle.com/ip/deploy/cs/ . Formerly Steltor CorporateTime, http://www.steltor.com/, until that firm's recent acquisition by Oracle. (That product is said to have emerged from Netscape Calendar.) Does IMAP, POP3, SMTP, E-mail, real-time conferences, voicemail, scheduling. Apparently implements all of the special, proprietary MS-Exchange Server RPC-based protocols for group discussion, scheduling, contact management,
Check out the list of packages included with Red Hat Linux 9. You'll find exactly zero non-free software.
Only because you brought the subject up:
"pine 4.44 A commonly used, MIME compliant mail and news reader." This code is source-available, but licensed under proprietary terms (no right to fork).
In pointing out this inclusion of the proprietary pine/pico/pilot package, I intend no criticism of Red Hat Software, Inc., which does it for perfectly understandable reason, given the pine MUA's wide appeal and lack of an open-source replacement acceptable to that customer base that doesn't suffer the same copyright encumbrance (as MANA does). Chris Allegretta's "nano" has nicely eliminated the pico problem, but ditching pine itself without seriously ticking off a fair number of people remains difficult.
When I saw that Red Hat had (by the 8.0 release) reduced the number of proprietary packages to just this one -- having pushed the envelope in jettisoning the old proprietary Java packages, ditched Navigator/Communicator in favour of Mozilla and Acrobat Reader in favour of xpdf, and actually helped write a replacement for xv -- I was (and remain) quite impressed. They've shown impressive leadership, in this area.
But it remains a (small) factual error to claim that the distribution is 100% free / open-source software.
Rick Moen
rick@linuxmafia.com
one mua is enough for everybody.
Why have one when you can have 115?
Rick Moen
rick@linuxmafia.com