[Tails-dev] Does Your Business Need a Lifeline?
Does Your Business Need a Lifeline? I know you have to read a lot of emails every day, but please take a moment to read on and learn about what is unfortunatey Australia's Best Kept Secret. However it could be the Winning Edge for you. If not now, but at one stage in the future. Just recently, one of our Directors was chatting with a friend who is a small business owner. His friend asked him to simplify how our unique business finance product works. So today we thought we'd take the time out to share with you the same analogy he used to explain how we provide assistance to businesses all over the country, just like yours . Many of you would already be purchasing a number of your products and stock on credit, typically with 30, 60, or 90 day terms to settle the account. When you borrow funds from HomeSec Business Finance, it’s not a whole lot different. We are a short-term business lender, typically lending from 1 to 6 months in duration. So in essence, it’s similar to the same agreement you have with your supplier, except we give you cash as opposed to a product. Our product is essentially a form of business bridging finance, which can settle within 24 hours of application. THE BENEFITS. It may be, that you have an opportunity to buy stock at a discounted rate, and are unable to get it on tick (credit), and so this is where we can potentially save the day for you. When you look at the profit you stand to make, and compare it with our funding costs, it’s really just another cost of doing smart business, and in most cases, it turns out to be a no brainer. Basically, if you couldn't get the money in time and if the financial loss is greater than the cost of the loan, then our short term bsuiness loans are not only a lifesaver, but a valuable secret weapon to have in your armoury. Plus, all costs are fully tax deductible. To gain an even deeper understanding on how our service could be a lifeline for your business, we’ve prepared a short ONE MINUTE video for you to watch at your leisure. There's More Good News It’s also common for us to fund loans for businesses with tax debts and various cash flow issues, especially since no banks will touch a business with tax issues. In this scenario, businesses will often borrow the funds from us to settle their tax debts, then refinance with their bank a couple of months later to pay us back. We are always available to answer any enquiries, and there is no such thing as a silly question. So if you’d like further clarification, please don’t hesitate to pick up the phone and speak to our friendly staff at HomeSec Business Finance today. The team at HomeSec 1300 93 83 87 www.HomeSecFinance.com.au Let's Get Started Now Online Loan Applications take just 90 Seconds, and you could be cashed up By Tomorrow! National Head Office: Suite 6 / 170 Underwood Rd, Ferntree Gully Vic 3156 Click here to leave mailing list___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Changing Tails 3.0 release date?
On Thu, 2017-06-01 at 10:18 +0200, intrigeri wrote: > hi! > > anonym: > > intrigeri: > > > I'll make the call as the 3.0 release manager if no consensus > > > emerges, > > After re-reading this discussion, it appears that the only people > substantially affected by this decision (apart of Tails users of > course) will be myself and our usual manual testers. So I'll make the > call by the end of this week, depending on how I feel about committing > to RM'ing an extra release. I may follow anonym's very reasonable > position, or go crazy for the sake of communication and > Debian/Tails/FOSS relationships. I'm undecided yet and want to sleep > on it and balance all this very carefully. > > > > A. Coordinate Tails 3.0 and Debian Stretch releases > > [...] > > > B. Don't bother and proceed as our calendar says > > > - Option A forces us to integrate Tor Browser 7.0 into Tails 2.x: > > > this work has been based on the Tails 3.x codebase so far. I don't > > > know if rebasing it onto the stable branch would be trivial, or > > > a lot of work. anonym, what's your feeling? > > Cherry-picking these commits will not result in any difficult conflicts > > (it's mostly > > about s/32/64/, and some jessie vs stretch test suite images). But there > > could be > > issues with running 7.0a4 on Tails Jessie/i386 -- we haven't tested the 7.x > > series at > > all on that platform. Still I definitely believe it quite a bit more likely > > to Just > > Work rather than introduce issues we don't see on Tails Stretch/amd64. So > > my feeling > > is that this should be an hour of work. > > OK, thanks for the insight! > > > > - Option B is less work, therefore it increases the chances that we > > > manage to make 3.0 build reproducibly, which gives us good > > > communication opportunities. So: > > > > > > [...] > > > > > > * anonym (who is our lead developer on the reproducibility front): > > > if we go with option B, how confident are you that 3.0 can > > > build reproducibly? #12608, #12567 and #12566 should be good > > > starting points. > > At least for me, locally, the only problem I see (after applying all > > unmerged fixes) > > is that Chris' patch for #12567 seems to miss some case. I've asked for an > > ETA of > > a fix. So assuming Chris is available, or I manage to identify and fix the > > issue, > > it's looking really good. :) > > Great :) > > > > Other pros/cons or thoughts? > > A con for option A: > > * Users will be prompted to do two updates within four days, which > > is a bit much both in terms of nagging frequency, bandwidth > > usage, and pure inconvenience. > > Absolutely. This will be particularly painful for those who will have > to do a manual upgrade to 2.12.1, as everyone will have to do a manual > upgrade to 3.0 anyway. > > On the other hand, if 2.12.1 is a thing, we give users almost two > months to upgrade to 3.0 (vs. 0 days if we don't release 2.12.1), > which is nice as they're often scared by such drastic change; also, > anyone affected by a serious regression can temporarily downgrade to > 2.12.1 until Tails 3.1 fixes their problem. > > So all in all it's not clear cut to me which option provides the > greater UX (once considering dozens of thousands of real-world users, > and not only some theoretical, ideal one who would immediately upgrade > to 3.0 and not have any big problem with it). Agreed IMHO users come first ... continuity is not an optional. 3.x can wait > > I'd also like to stress (pun intended!) the fact that option A's "more > > work" (as in > > an extra release, 2.12.1) is not so suitable at this time. I think we're > > collectively > > exhausted, and should try to take whatever breaks we can. > > OK, thanks for sharing, I want to take this into account. > > I'm committed to be the RM for 3.0 already; I understand you don't > feel like taking care of 2.12.1 so let's assume I would handle both > releases myself (if I convince myself that option A is the way to go). > And then the additional work is only on my shoulders (I don't feel > exhausted personally) and manual testers' (no idea how they feel about > it, but we had no problem getting manual testers recently, did we?). > > In passing: we have 4 emergency releases budgeted this year, and we > did none of them yet. Given this data + the feelings you're sharing, > I think we should acknowledge that we probably won't do more than > 2 emergency releases this year. If you agree, I'll update our > accounting accordingly, so nobody counts on (paid) RM work that's > unlikely to happen in practice, first because there's no need for it, > second because our RMs are not exactly thrilled at the idea of doing > this work. Fair enough? > > > Yup, I'm quite a lot in favor of option B. > > Got it. > > > > The decision algorithm I intend to use is: > > > > > > - If the reproducible builds people tell me they can make 3.0 > > > reproducible and communicate
Re: [Tails-dev] Changing Tails 3.0 release date?
hi! anonym: > intrigeri: >> I'll make the call as the 3.0 release manager if no consensus >> emerges, After re-reading this discussion, it appears that the only people substantially affected by this decision (apart of Tails users of course) will be myself and our usual manual testers. So I'll make the call by the end of this week, depending on how I feel about committing to RM'ing an extra release. I may follow anonym's very reasonable position, or go crazy for the sake of communication and Debian/Tails/FOSS relationships. I'm undecided yet and want to sleep on it and balance all this very carefully. >> A. Coordinate Tails 3.0 and Debian Stretch releases [...] >> B. Don't bother and proceed as our calendar says >> - Option A forces us to integrate Tor Browser 7.0 into Tails 2.x: >>this work has been based on the Tails 3.x codebase so far. I don't >>know if rebasing it onto the stable branch would be trivial, or >>a lot of work. anonym, what's your feeling? > Cherry-picking these commits will not result in any difficult conflicts (it's > mostly > about s/32/64/, and some jessie vs stretch test suite images). But there > could be > issues with running 7.0a4 on Tails Jessie/i386 -- we haven't tested the 7.x > series at > all on that platform. Still I definitely believe it quite a bit more likely > to Just > Work rather than introduce issues we don't see on Tails Stretch/amd64. So my > feeling > is that this should be an hour of work. OK, thanks for the insight! >> - Option B is less work, therefore it increases the chances that we >>manage to make 3.0 build reproducibly, which gives us good >>communication opportunities. So: >> >>[...] >> >> * anonym (who is our lead developer on the reproducibility front): >> if we go with option B, how confident are you that 3.0 can >> build reproducibly? #12608, #12567 and #12566 should be good >> starting points. > At least for me, locally, the only problem I see (after applying all unmerged > fixes) > is that Chris' patch for #12567 seems to miss some case. I've asked for an > ETA of > a fix. So assuming Chris is available, or I manage to identify and fix the > issue, > it's looking really good. :) Great :) >> Other pros/cons or thoughts? > A con for option A: > * Users will be prompted to do two updates within four days, which >is a bit much both in terms of nagging frequency, bandwidth >usage, and pure inconvenience. Absolutely. This will be particularly painful for those who will have to do a manual upgrade to 2.12.1, as everyone will have to do a manual upgrade to 3.0 anyway. On the other hand, if 2.12.1 is a thing, we give users almost two months to upgrade to 3.0 (vs. 0 days if we don't release 2.12.1), which is nice as they're often scared by such drastic change; also, anyone affected by a serious regression can temporarily downgrade to 2.12.1 until Tails 3.1 fixes their problem. So all in all it's not clear cut to me which option provides the greater UX (once considering dozens of thousands of real-world users, and not only some theoretical, ideal one who would immediately upgrade to 3.0 and not have any big problem with it). > I'd also like to stress (pun intended!) the fact that option A's "more work" > (as in > an extra release, 2.12.1) is not so suitable at this time. I think we're > collectively > exhausted, and should try to take whatever breaks we can. OK, thanks for sharing, I want to take this into account. I'm committed to be the RM for 3.0 already; I understand you don't feel like taking care of 2.12.1 so let's assume I would handle both releases myself (if I convince myself that option A is the way to go). And then the additional work is only on my shoulders (I don't feel exhausted personally) and manual testers' (no idea how they feel about it, but we had no problem getting manual testers recently, did we?). In passing: we have 4 emergency releases budgeted this year, and we did none of them yet. Given this data + the feelings you're sharing, I think we should acknowledge that we probably won't do more than 2 emergency releases this year. If you agree, I'll update our accounting accordingly, so nobody counts on (paid) RM work that's unlikely to happen in practice, first because there's no need for it, second because our RMs are not exactly thrilled at the idea of doing this work. Fair enough? > Yup, I'm quite a lot in favor of option B. Got it. >> The decision algorithm I intend to use is: >> >> - If the reproducible builds people tell me they can make 3.0 >>reproducible and communicate about it _only_ if we pick option B, >>then I'll go this way. [...] > [I might consider sabotaging option A by pretending, as > a reproducible buids person, that "Tails 3.0 will only be > reproducible if we pick option B". Will I have to? :)] I'm sorry I even asked this question, as it doesn't make any sense: the only work option A adds to our reproducible builds
