new version
Comments
-
If I upgrade my v9 for windows to v10 Windows, will I then be able to use the Linux v10 version without extra fee??
I am eager to try out the new functions, but will not spend dubble up on license cost.
Best regards,
Mads Boserup Lauritsen
0 -
I am glad to hear you are developing an affordable AudoCAD alternative for LINUX. like everyone else, as soon as this is available, I will give window OS the boot. Please put me down for the beta test when available.
Jesse
0 -
We are monitoring the development of this program for a long time and want to be among the first to find out more about it. We want to take part in beta testing of this program and do what one can on this stage.
0 -
I've been waiting for this for ten years now... ...no market they all told us. Lets just wait and see what happens when there's an at least half way passable port of an at least half way usable CAD system with an at least half way findable sales chanel. It seems obvious to me.
steriotypical Linux user = well educated professional with a high probability of an engineering or similar background...
steriotypical CAD user = ... <sarcasm> yeah right! no market there. </sarkasm>
Well, I for one am excited.
0 -
I think there's another reason that prevents linux release.
Bicscad Classic V10 English version offered on national webpage (www.bricsys.pl) is 40% more expensive than on international webpage.
That equals the price for native version (merely an issue of font encoding).
That seems like the strategy to make profit of those who can't break the barrier of their native language.
If we can't use linux version, then we are expected to pay for windoze release.
Bad thinking? Perfectly right. No effort from bricsys, money from linux users.
I don't think that developers are to be blamed, they do what they can, but something may be in that with management.
0 -
Dear M M,
I liked your idea about viral campaigning for our LINUX version (tread #117 on this forum).
But not this time. Although I planned not to react any longer till we launch the first alpha or beta of Bricscad for LINUX, this last insinuation (#126) forces me to react immediately.
For once and for all: we are working like hell on the LINUX product with the majority of the team now, and we will release something as soon as we can. Cross the fingers for something end of December, 2009. Your remark about regional price difference has no ground and has no influence at all on the LINUX release. Bricsys has no tradition nor intention to force/mistreat its users as you say.
I kindly ask everybody to stop speculating.
erik
0 -
I am like a kid waiting for Christmas. I keep checking under the tree (metaphorically speaking) for my CAD for linux.
Please, Please, Please Santa may I have a have a mint flavoured DEB.
0 -
#128: I'm also impatiently waiting, but I could well do without a .deb, .rpm etc (although I run debian).
I would prefer a .tgz that contains some decent installation instructions, giving me more choice and the developers a bit less work.
Anyway, if bricsys should want to support native packages for the popular distributions, I hope that they won't follow their guidelines and scatter the installation all over the filesystem, but install everything below a (version-numbered) folder in /opt (so the packaging system is used only for dependency handling).
IMHO, big commercial applications shouldn't put anything outside /opt except for symlinks (usr = Unix System Resources!), otherwise it will be pretty difficult to have several versions running alongside, and that would be a big issue for professional use.
0 -
<!-- @page { size: 21cm 29.7cm; margin: 2cm } P { margin-bottom: 0.21cm } -->
Dear Erik
I come here every day looking to see if there is news, I am looking forward to having Bricscad on linux. I want to know if it serves WINE and how to run the VBA (# 117).
Thanks for the effort you are doing0 -
<!-- @page { size: 21cm 29.7cm; margin: 2cm } P { margin-bottom: 0.21cm } -->
Sorry if I made confusion in the previous post, but do not know English
"" Dear Erik
I come here every day looking to see if there is news,
I am looking forward to having Bricscad on linux.
I want to know if it serves WINE and how to run the VBA (# 119).
Thanks for the effort you are doing ""0 -
@ Knut
Since we're all talking about our preferences, I would prefer a .deb (Actually, I would prefer a .tar.bz2 with an .ebuild, but that's not going to happen)
Why would I prefer a .deb?
- because I want all the bits and peices of the program to 'go where they belong'.
- Then I want them to be easily removable & replaceable during the beta testing process.
- Then I want them to be easily removable & replaceable when the final version arrives.
- Then I want incremental updates in the v10 series done for me.
- There should be no problem when v11 arrives. You simply make it a different package. This has been done successfully by any number of packages.
I don't like the practice of cluttering up the /opt tree with closed source packages. It's indicative of a package that has failed to grasp the elegant simplicity of the unix file system. When I first started getting under the hood, I used to think the filesystem was a mess (Don't get me wrong. Most distros make their filesystem into a cluttered shambles.) Then I sat down and researched the rational of the different branches with the aim of simplifying it. The underlying logic is beautiful. It pays to work with the system.
0 -
my guess package will be ships as a distro independed installer. (as most proprietary packages allready mades). .sh .run and so on
0 -
Andrey
I have a couple of games that install from shell scripts. Other than that most commercial packages I've encountered use the various package management systems. What are you going to do when the final version arrives?
- install the final over the top of a beta version & hope for the best,
- reinstall your system or
- try to use a windows style 'uninstall' option in the script.
All of those options sound very Windows. Having every package independently updated is one of the most ridiculously broken aspects of Windows.
0 -
Q4 is ending. I am excited waiting Bricscad for Linux. Count me for beta testing. For the packaging I think that installing from source is the best solution. Anyway if you want a package the best packet manager is RPM. For Debian users can get it with Alien.
0 -
The most popular flavour of linux at the moment is Ubuntu, a deb based program. Does it not make sense to provide a Deb package?
At this point packaging is of small concern. Geting the software out to us for testing the important issue.
0 -
@ Erik Lundberg:
Maybe this is not the right place to discuss the pros and cons of package management, but I'll try to explain a bit further what I meant in #129:
Of course you can easily deinstall or update any .deb, but in my experience it almost never allows for what I want, which is installing a new version for testing while continuing to use the older one for production work. Although this might theoretically well be possible with package management, it practically isn't, because allmost all files in a package would need a version suffix to prevent overwriting when installing in the OS file structure.I can not understand why a properly named folder in /opt should lead to clutter - it rather gives you the opportunity to browse through a package's files easily and keeps the system folders more readable to humans (less chaotic systems like Solaris have done so for decades, to my knowledge without much complaint). This doesn't imply any of the problems you mentioned in #134, and can also circumvent another ms-windows plague: having to give installers (and a .deb is one) write access to system folders.
Installing under /opt also gives me the freedom to switch linux flavors as I like - I just have to boot another distro, remount my opt-partition and type (usually) /opt/<programdir>/<programname> to keep using my favorite apps.
But in the end, I agree with Ken Mole - getting the thing out is much more important now than gift-wrapping it.0 -
Sounds like you really want a .tar.bz2 with an .ebuild too. (^_^)
I wasn't suggesting that putting everything in the /opt system was cluttered. I was suggesting that it missed the whole point of the unix filesystem structure and discarded all of the benefits associated with sharing in the big kids' sand pit.
Putting everything in /opt in the manner you're suggesting rapidly takes you down the path to a statically linked blob with every library required (except for maybe the c library) in the /opt folder, regardless of whether or not it's provided elsewhere on the system. It sounds good to just be able to reboot into a different distro, but you're forgetting about libraries and dependencies. Dependency management is a beautiful thing. Having to do it manually can quickly become a nightmare.
What you're proposing is a quick and dirty way to get it to work most of the time. I was rather hoping for an elegant solution more in keeping with the conventional wisdom on every linux distro that I'm aware of.
If you have multiple distros installed consider making one a testing install rather than testing on a production system.
0 -
@ Erik:
Well, I think I could also live with an .ebuild. Let's hope that bricsys - confronted with such an overwhelming user demand - will open the sources for Xmas.
But if not, I'll still stick to my initial claim that closed, commercial applications that are not part of e.g. the debian project and did not go through its unstable/testing/stable cycle should not merge with the OS and give the users the possibility to install to a location of their choice without needing root privileges. The same goes for bleeding-edge FOSS stuff (I probably always have min. 3 different blender builds under /opt), unless you want to turn your whole OS into a playground.
I don't question the linux file system hierarchy (although you could reasonably do so, look for example at gobolinux) and am perfectly happy with apt; thorough dependency handling and testing is why I am using debian stable, after all.
The ideal solution for an application like bricscad (that presumably doesn't tamper with core libraries and wants a smooth installation experience for neophytes) might rather be a dependency-aware cross-distribution installer like autopackage or listaller, but they are not widely used.
However, to me, anything relocatable will be fine.
PS: mounting an /opt-partition on different distros might be quick and dirty and is certainly not a proven practice, but it works for me, and I prefer using ldd and copying/symlinking a couple of .so to /opt/lib against fighting with distribution internals...0 -
I appreciate your comment on fighting with distro internals. As much as non-gentoo people talk about Gentoo being for control freaks, the main reason I use it is that I know that any limitations I encounter are almost invariably my own. Nothing worse than an automagic tool stopping you from getting something unusual done; especially when you know it would be simple to just do it the old way.
Erik
0 -
@ Erik
Perhaps I should be using gentoo, too. When I looked at it (around 2004 or so), I really liked the concept, and especially that they seemed to favor documentation over what you called "automagic tools". What kept me from switching was mainly laziness and a slow internet connection.
To take the turn back to this forum's subject: with a CAD application that I plan to use several hours on several days a week, it seems quite irrelevant to me whether the initial setup takes 30 seconds or 30 minutes. I hope that bricsys doesn't get lured into this eyecandy race that is so common nowadays, but sticks to something functional, flexible and simple (and that's not only my wish for the installation, but for the whole thing, Amen).
0 -
not really agree that CAD people will use source based-distro's... it is funny sounds. you have to waste hours!!! to build gentoo and you did not want to loose some seconds more with installer?
We have a comperation of prebuild kernel and builded from sources... there is almost no difference. but when the monkey is building kernel... there is a high probability that kernel will work worse, over prebuild one.
did you think this will be cool to people to link
ln somelibxxx.so somelib.so
setenv SOMEVAR
by hands?
if you're really so fammilar with linux, nothing stops you from BricsCAD*.run --help
find something like extract-only option... but most people will be happy with ordinary installation from installer.
personally for me there is no difference how this will be shipes. There is always README instruction. But if yoou look how google earth, nvidia, ati ships there proprietary software...
I want that it will run(so I can work without program fail), print to A4, A3, A2 (will be cool if it automaticaly prints A2 @ 2*A3 or A3 @ 2*A4) support my national chars, can connect to some local(or remote) DB mysql or whatever... autolisp(also python will be cool) support.
0 -
Well, as a typical Ubuntu end-user, I'll just be glad if the package was a .deb.
Beside, as I said, I'm an end-user, on Ubuntu for many reason, and one of them is that I don't agree with the monopol position of MS.
I dream about a Ubuntu, or whatsoever Linux distribution, architectural-design oriented. Pre-instaled tools for students and professionals,a ready (easy) to use tool box, to really focus on what is really important in architectural practice, design, instead of spendig so much time to deal with computer problems.
My 2 cents.
0 -
I hope we'll have the Linux beta version for Christmas :-)
Max
0 -
Cadê o bricsLinux?? estou esperando para o Natal!!!!
0 -
Sounds like most regular users want a deb. Not really very surprising. I for one wouldn't stand too close to the help forum if we don't get a deb that 'just works' with ubuntu. That said, if it came in a zip file, I'd be happy to get it, as long as I get it.
@ Knut
portage, ebuilds and the like have a feature called 'slots'. Slots are cool. They do what you seem to want in a fairly elegant way. Ebuilds are basically shell scripts with a lot of package handling functions available. They could, for example, convert a deb into a tgz and install it... (^_^)
0 -
I think most people will be able to figure out how to load the program,in any format, if they are give some clear instructions.
Not all users are computer geeks, but given the nature of the linux community, most are educated and willing to go the few extra steps for a clean install.
Yes a Deb package would be in Bricscad best interest, but not completey necessary.
Just get the package out, and let us beta test.
0 -
Any (good) new ?
Max
0 -
countdown
Merry Christmas in Bricsys
0 -
i guess santa found out we werent good kids........
0 -
... looking forward to not checking this thread twice daily....
0
