So buy/build/whatever an accounting program that modularizes data access, i.e. you have access to enter your own purchases but not to look up salaries.
I routinely work with MAS 90; for a basic system such as you describe, I think it would run you a one-time cost in the low five digits, plus a small percentage of that amount annually for updates and support. There may be cheaper programs that also offer modular data access (though I don't know any off the top of my head, and they probably have less features in other areas - which is fine if the extra features are things you don't need).
Now once again, why should you make more work for either yourself or others?
Note the implicit disclaimers "at least" and "if necessary" in the grandparent post. Obviously this shouldn't happen - this isn't the best case, in fact it's the worst case. The best case is one in which the community of those-who-already-grok-the-darn-thing remains vigorous.
The relevant questions are: How much confidence do you place in your ability to choose software whose community will remain vigorous? Absent such confidence, would you rather have your worst-case scenario be difficult or damn-near-impossible?
The grandparent post points out that it's difficult to rebuild the level of expertise that the former community possessed. However, you probably don't need to. You're not dealing with many different people/companies, whose needs may vary widely; you're only dealing with your own needs. This greatly reduces the extent to which you need to expand the software in future, and even the extent to which you need to understand what the software currently does (because you can generally just ignore any features you don't use).
but if you get beyond the surface of the data issues,
The data issues are not merely a surface issue! Even a good interface is useless without good content, and mis-classifying Bach as Classical instead of Baroque is pretty damn bad.
Speaking of the interface, it's slow and clunky-feeling. Also, the one composer bio I checked out (Vivaldi) has a huge image at the top; you can't see any of the text without scrolling down. I'd much prefer a smaller image with text wrapped around it.
When it's authentication time, Client goes to Ticket Grantor and says, "I want to talk to Server, and here's my key."
No, it just says "I want to talk to Server". Ticket Grantor then gives out a session key encrypted with Client's password. And now this next bit:
Client unencrypts the session key using its own key. If Client really is who it says it is, the unencrypted key will be correct. Client goes to Ticket Grantor with the ticket-granting ticket and the session key and says, "Look, I can do it! It's me! Gimme a real ticket already so I can talk to the server."
Okay, a one-step disconnect that breaks the standard is clearly bad, but why can't one-step disconnects be added to the standard?
Googling on (rfc tcp/ip "disconnect request") turns up the seemingly-relevant section 2.4 of RFC 1859, and it seems that one-step and two-step disconnects would naturally correspond to Abort Disconnect and Synchronous Disconnect, respectively.
Besides ACK (and the standard-breaking no-response), what other options does the client have? If it sends a NAK or whatever, then what is the server supposed to do, besides send another disconnect-request?
Impressive eye candy, but it'd be more useful to see a table with all the waypoints in a column. I also agree with another poster who pointed out that the distances should be in a separate column. (Yahoo gets both these points right.)
This sounds like yet another case of "'perfect' is the enemy of 'good'".
Don't worry about which of the umpteen options is best. Try out as many or as few as you like, and pick one that seems to be good enough.
I'm running Red Hat 9 and Gnome 2.2 (with a couple of dockapps hacked in via gnome-swallow). Sure, I'd like to have apt-get and gDesklets and more flexible panels - if I got a new computer tomorrow, I'd put Ubuntu on it - but my current arrangement works pretty well.
(I do have Synaptic installed, but the underlying RPM database is slightly borked, and I have insufficient incentive to fix it. Many things install just fine via RPM; those that don't, I live without.)
That's a search for "fired chicken". Given that UNT's menu includes "Korean fired chicken", it seems pretty relevant to me.
I tried searching MSN for friend chicken (spelled correctly this time) and search result number one... brr, spooky.
Neither Google nor Yahoo turns up either of those links in the top ten, searching for 'fried chicken' or 'friend chicken' or 'fired chicken'.
More generally, I noticed that Yahoo has adopted Google's "did you mean X?" approach to words it thinks are probably misspelled, whereas MSN has not (at least so far).
My company is pretty similar, except instead of writing a specific app, we do consulting and tech support on another company's general app, and write custom modifications for a few clients who need/want them badly enough to pay extra.
someone else suggested that the P in OnLAMP was for Postgres
At best, that's stretching things. LAMP traditionally represents OS, web server, database, and programming language (in that order): hence Linux, Apache, MySQL, (Perl or whatever).
1) Linux + (normally TFT, occasionally CRT) + (grayscale anti-aliasing "Best Shapes" vs RGB sub-pixel anti-aliasing)
2) Windows + (normally LCD, sometimes CRT) + (ClearType vs their older anti-aliasing vs grc.com's sub-pixel demo)
On Windows, ClearType is mostly better, but worse in a few parts; grc.com's demo is just lousy, even on an LCD, and even after tweaking all the options. On Linux, grayscale is slightly better than ClearType, RGB sub-pixel is slightly worse. Monitor type doesn't seem to make much difference to any of it.
As usual, YMMV, especially since (a) I have lousy vision in the first place and (b) I haven't really carefully observed how monitor type affects things.
It is being proposed as an intermediate language for easy translation. From TFA:
Programmers will not see or edit XML tags; instead, their editors will render these models to create human-friendly views, just like Web browsers and other WYSIWYG editors. For example, a program stored on disk like this:
// Only replace below threshold if (record.age < threshold) { record.release(); }
Crucially, code will not be stored as uninterpreted CDATA within XML documents and programmers will not see (much less type in) XML tags. Such a representation would have all the disadvantages of JSPs, Ant, and other hybrid systems, without bringing any tangible benefits. Instead, XML will represent the program's deep structure.
Laptops, PDAs, and tablet PCs have made a lot of progress in this area. Folding keyboards are a neat idea.
My personal needs at work are reasonably served by a laptop, a cell phone with basic contact and calendar functions, and a physical notepad. I'm stuck with a desktop PC (albeit a solid personal server) at home; money permitting, I'd add a better-cooled laptop with wifi, and headphones to shut out the blare of the TV.
Re:The PC evolving into a dataserver
on
The Future of the P.C.
·
· Score: 4, Informative
The modern PC, with it's QWERTY keyboard (a design meant to hinder speed, not help it)
"Frequently-used pairs of letters were separated in an attempt to stop the typebars from intertwining and becoming stuck, thus forcing the typist to manually unstick the typebars and also frequently blotting the document."
Beyond this, there's an awful lot of debate over QWERTY vs. alternatives (particularly Dvorak), which I shan't get into here.
isn't the premiere choice for entering data.
It damn well is for me. I touch-type, and any slight edge I might gain from Dvorak is easily outweighed by (a) QWERTY's ubiquity and - more importantly - (b) the inherent slowdown incurred by thinking and typing simultaneously. And don't bother suggesting voice recognition; my voice would get tired a lot more quickly than my fingers do. (For businessmen who spend lots of time producing correspondence, voice recognition would make a lot more sense.)
Adding a link from the main page would help. That said, http://suggest.google.com/ would seem the logical choice for a post-beta URL.
Re:Evil hands with just use yesterdays "or later"
on
Revising the GPL
·
· Score: 1
Ah, but let's examine what they can and can't do from there.
Suppose that the evil hands write Evil GPL 3 to say "we can use it however we want, and no one else can use it without paying us One Million Dollars". Okay, they can create and release a closed fork of yesterday's source, which is bad. However, they cannot do a thing to today's source (which explicitly rejects Evil GPL 3), and they can't actually stop others from using yesterday's source openly (because they still have permission from Good GPL 2).
No I haven't been silenced, I have only been modded flamebait the lowest possible ranking which will prevent 90% of slashdot readers from seeing my informative post on what annoyances they will encounter if they install Firefox like I did.
This is easy to avoid, though-- just tweak your phrasing a bit, so that you don't present the connotation of "I'm loud, I'm rude, I'm right, and anyone who doesn't like it is a jackass".
Likely to be modded down: "This change sucks!"
Less likely to be modded down: "I don't like this change because of X, and there's no easy way (I don't consider about:config to be easy) to change it."
It's not too difficult for a reader to perform the mental translation from the former to the latter. But will most of them bother? Should most of them bother? Perform the translation yourself and you should receive a much nicer reception.
On the MIME type issue, it occurs to me now that Options - Downloads - File Types should allow adding new entries - with "assume MIME type X and open inline" as one of the capabilities. Perhaps a stock set of entries for all the image types that FF can display inline without needing a plugin? Examining byte headers isn't out of the question, either (look at the 'file' command in *n*x).
Putting dangerous items, like the CLOSE button next to the Maximize button in an app that doesn't ask you if you are sure you want to close the app, or an "open all in tabs" option at the bottom of a list which might have a hundred items in it, are very stupid design decisions.
If a folder has a hundred items in it, then this is only a risk for a few of those hundred. More to the point, if a folder has a hundred items in it, then you should have organized things into sub-folders long ago.
I use "open in tabs" on purpose (to view my daily webcomics, in roughly four groups of eight apiece) and I damn well want it at the bottom of each folder menu. Of course, if there's an option somewhere for users to turn it off, then that's fine and makes us both happy (or at least happier).
Re:The GPL/LGPL worries me....
on
Revising the GPL
·
· Score: 2, Informative
1) The FSF can create different versions in the future, and everything under the old licenses is effectively retroactively dual-licensed.
Some projects specify "version X alone", though the FSF recommends "version X or later" for the explicitly-stated purpose of making retroactive dual-licensing work.
The FSF consists of little more than Richard Stallman.
This seems debatable. Someone with concrete evidence want to weigh in?
What happens when Stallman gets hit by a bus? Who controls the FSF (and through it GPL) then? How many millions would even partial control of the GPL be worth these days? Maybe loosen those "troublesome restrictions"?
If it appears that the FSF will fall into evil hands, then I would expect many OSS developers to hurry up and release a new version with "version X alone" style licensing.
2) The LGPL is all based on object "linking". What the hell is the legal definition of "linking"? The idea of linking will become increasingly irrelevant in the future; it's like a 1980's OS-specific license.
3) What happens to the legal status of GPL'ed projects when some company manages to retroactively claim a patent on some double click feature? At that point, does it not become illegal to distribute the software under the terms of the GPL? Won't that invalidate the whole license for that software package?
A patent that broad would also hit lots of commercial software, whose authors would presumably tie things up in court until they could invalidate the patent (or the relevant bits of the patent system).
Re:The GPL should be a little friendler.
on
Revising the GPL
·
· Score: 1
I don't want [my open source program] to become part of MS Office without me getting some Bucks for it.
Define "part of". (I'm going to oversimplify a bit here; anyone with more precise understanding is welcome to correct the fuzzy bits.)
If the definition that interests you is "tightly integrated", then MS can't legally use your program without releasing Office under the GPL, which they're not about to do.
If the definition that interests you is "loosely integrated", then we need to discuss more. For instance, I work with a commercial accounting package whose manuals are in PDF format, and which includes Adobe Acrobat Reader on the install CDs. (I know AAR is not GPL, but my point here is not about GPL; it's about loose integration in general.) Assuming that the integration is limited to the accounting package going "hey, Windows, run this PDF file using whatever program you want", then this is clearly loose integration; you could replace AAR with another PDF-displaying program, and the accounting package wouldn't care. Now then, is Adobe entitled to make money on every copy of this CD that's sold? Why or why not? (Actually, for all I know, Adobe might pay to get AAR onto certain CDs-- as a loss leader for full-blown Acrobat, which can edit PDFs as well).
Re:Example of a REALLY SIMPLE Plone site?
on
Two Books On Plone
·
· Score: 1
I recently set up a wiki for one of the sites I've designed, in response to a request for a comments page. This may be simpler than you want to get, though.
I used PmWiki because it was really easy to initialize. There were some automated wikispam attacks, so I configured it to require a password (which humans can easily figure out) for editing. (The site doesn't have lots of people watching for vandalism and repairing it. I'm not worried about manual vandalism. Nor do I want to futz around with configuring the box to send e-mail, apart from sending OS-level messages to root@localhost.)
I might someday look into using Zope and/or Plone to administer my other main site, which is somewhat more substantial, and currently implemented in manual HTML + CSS. It contains a few info submission forms using a FrontPage extension, though. I'm not hot on the idea of re-engineering those, nor the idea of doing anything more than FTP uploads to what I assume is a yucky IIS box.
Slashdot Mirror
The canonical game (7 columns, 6 rows) has been solved.
So buy/build/whatever an accounting program that modularizes data access, i.e. you have access to enter your own purchases but not to look up salaries.
I routinely work with MAS 90; for a basic system such as you describe, I think it would run you a one-time cost in the low five digits, plus a small percentage of that amount annually for updates and support. There may be cheaper programs that also offer modular data access (though I don't know any off the top of my head, and they probably have less features in other areas - which is fine if the extra features are things you don't need).
The relevant questions are: How much confidence do you place in your ability to choose software whose community will remain vigorous? Absent such confidence, would you rather have your worst-case scenario be difficult or damn-near-impossible?
The grandparent post points out that it's difficult to rebuild the level of expertise that the former community possessed. However, you probably don't need to. You're not dealing with many different people/companies, whose needs may vary widely; you're only dealing with your own needs. This greatly reduces the extent to which you need to expand the software in future, and even the extent to which you need to understand what the software currently does (because you can generally just ignore any features you don't use).
Speaking of the interface, it's slow and clunky-feeling. Also, the one composer bio I checked out (Vivaldi) has a huge image at the top; you can't see any of the text without scrolling down. I'd much prefer a smaller image with text wrapped around it.
If it's sufficiently important to you, then you can pay someone else to grok the code for you. That option is also unavailable with closed-source.
Googling on (rfc tcp/ip "disconnect request") turns up the seemingly-relevant section 2.4 of RFC 1859, and it seems that one-step and two-step disconnects would naturally correspond to Abort Disconnect and Synchronous Disconnect, respectively.
Besides ACK (and the standard-breaking no-response), what other options does the client have? If it sends a NAK or whatever, then what is the server supposed to do, besides send another disconnect-request?
Impressive eye candy, but it'd be more useful to see a table with all the waypoints in a column. I also agree with another poster who pointed out that the distances should be in a separate column. (Yahoo gets both these points right.)
Don't worry about which of the umpteen options is best. Try out as many or as few as you like, and pick one that seems to be good enough.
I'm running Red Hat 9 and Gnome 2.2 (with a couple of dockapps hacked in via gnome-swallow). Sure, I'd like to have apt-get and gDesklets and more flexible panels - if I got a new computer tomorrow, I'd put Ubuntu on it - but my current arrangement works pretty well.
(I do have Synaptic installed, but the underlying RPM database is slightly borked, and I have insufficient incentive to fix it. Many things install just fine via RPM; those that don't, I live without.)
That's a search for "fired chicken". Given that UNT's menu includes "Korean fired chicken", it seems pretty relevant to me.
... brr, spooky.
I tried searching MSN for friend chicken (spelled correctly this time) and search result number one
Neither Google nor Yahoo turns up either of those links in the top ten, searching for 'fried chicken' or 'friend chicken' or 'fired chicken'.
More generally, I noticed that Yahoo has adopted Google's "did you mean X?" approach to words it thinks are probably misspelled, whereas MSN has not (at least so far).
My company is pretty similar, except instead of writing a specific app, we do consulting and tech support on another company's general app, and write custom modifications for a few clients who need/want them badly enough to pay extra.
The same thing works in Windows and Linux.
I've tried the following:
1) Linux + (normally TFT, occasionally CRT) + (grayscale anti-aliasing "Best Shapes" vs RGB sub-pixel anti-aliasing)
2) Windows + (normally LCD, sometimes CRT) + (ClearType vs their older anti-aliasing vs grc.com's sub-pixel demo)
On Windows, ClearType is mostly better, but worse in a few parts; grc.com's demo is just lousy, even on an LCD, and even after tweaking all the options. On Linux, grayscale is slightly better than ClearType, RGB sub-pixel is slightly worse. Monitor type doesn't seem to make much difference to any of it.
As usual, YMMV, especially since (a) I have lousy vision in the first place and (b) I haven't really carefully observed how monitor type affects things.
A year?! I wanna beat people up right now!
My personal needs at work are reasonably served by a laptop, a cell phone with basic contact and calendar functions, and a physical notepad. I'm stuck with a desktop PC (albeit a solid personal server) at home; money permitting, I'd add a better-cooled laptop with wifi, and headphones to shut out the blare of the TV.
Adding a link from the main page would help. That said, http://suggest.google.com/ would seem the logical choice for a post-beta URL.
Suppose that the evil hands write Evil GPL 3 to say "we can use it however we want, and no one else can use it without paying us One Million Dollars". Okay, they can create and release a closed fork of yesterday's source, which is bad. However, they cannot do a thing to today's source (which explicitly rejects Evil GPL 3), and they can't actually stop others from using yesterday's source openly (because they still have permission from Good GPL 2).
Likely to be modded down: "This change sucks!"
Less likely to be modded down: "I don't like this change because of X, and there's no easy way (I don't consider about:config to be easy) to change it."
It's not too difficult for a reader to perform the mental translation from the former to the latter. But will most of them bother? Should most of them bother? Perform the translation yourself and you should receive a much nicer reception.
On the MIME type issue, it occurs to me now that Options - Downloads - File Types should allow adding new entries - with "assume MIME type X and open inline" as one of the capabilities. Perhaps a stock set of entries for all the image types that FF can display inline without needing a plugin? Examining byte headers isn't out of the question, either (look at the 'file' command in *n*x).
I use "open in tabs" on purpose (to view my daily webcomics, in roughly four groups of eight apiece) and I damn well want it at the bottom of each folder menu. Of course, if there's an option somewhere for users to turn it off, then that's fine and makes us both happy (or at least happier).
If the definition that interests you is "tightly integrated", then MS can't legally use your program without releasing Office under the GPL, which they're not about to do.
If the definition that interests you is "loosely integrated", then we need to discuss more. For instance, I work with a commercial accounting package whose manuals are in PDF format, and which includes Adobe Acrobat Reader on the install CDs. (I know AAR is not GPL, but my point here is not about GPL; it's about loose integration in general.) Assuming that the integration is limited to the accounting package going "hey, Windows, run this PDF file using whatever program you want", then this is clearly loose integration; you could replace AAR with another PDF-displaying program, and the accounting package wouldn't care. Now then, is Adobe entitled to make money on every copy of this CD that's sold? Why or why not? (Actually, for all I know, Adobe might pay to get AAR onto certain CDs-- as a loss leader for full-blown Acrobat, which can edit PDFs as well).
I used PmWiki because it was really easy to initialize. There were some automated wikispam attacks, so I configured it to require a password (which humans can easily figure out) for editing. (The site doesn't have lots of people watching for vandalism and repairing it. I'm not worried about manual vandalism. Nor do I want to futz around with configuring the box to send e-mail, apart from sending OS-level messages to root@localhost.)
I might someday look into using Zope and/or Plone to administer my other main site, which is somewhat more substantial, and currently implemented in manual HTML + CSS. It contains a few info submission forms using a FrontPage extension, though. I'm not hot on the idea of re-engineering those, nor the idea of doing anything more than FTP uploads to what I assume is a yucky IIS box.
In case anyone is interested:
Larger site
Smaller site