Please create an account to participate in the Slashdot moderation system


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Submission + - Microsoft abandons Azure RemoteApp, yields to Citrix

Mike Sheen writes: An email sent to Azure RemoteApp subscribers today alerts customers to the discontinuation of the RemoteApp service.
Azure RemoteApp is an offering on the Microsoft Azure platform to deliver Windows applications using a thin client. Any Windows application installed on an Azure VM image could be delivered for a monthly fee to Windows, Mac, iOS and Android platforms. The number of VM's provisioned was automatically managed on-demand.
Today, Microsoft announced that it had decided to "wind down" the Azure RemoteApp offering and touted an alternative product by Citrix — XenApp "Express" which is still in development. An email to existing subscribers stated the following:
"New trials and purchases of Azure RemoteApp are no longer available as of now. Existing paid customers actively using Azure RemoteApp can use the service one year past our announcement date, so that they can migrate with minimal business disruption".
No pricing, or expected availablity of the Citrix XenApp "Express" were provided. Seems like adopters of RemoteApp are now in for a period of uncertainty.

Comment Re:Are you exposing customers? (Score 1) 159

Since these are reported, but not necessarily fixed bugs, if someone is interesting in attacking one of your customers, you are giving them a gold mine of potential attack information. I believe in responsible disclosure, but it is one thing to tell your customers. Something else to tell the world, especially before it is fixed.

That is a valid point.

We're quite diligent in making sure nothing which would compromise security of existing customers is visible - I am well aware of the risk, and to use the Australian vernacular - shitscared - of exposing such information.

We do, however, have a few bugs crop up every now and then that support staff annotate the bug with a customer name that flagged the issue, so when they come to test the fix they have a way of notifying them how far it is along the resolution is for them. That is not really directly putting customers at risk - but it's unprofessional and I really hate that. It's like they use Bugzilla as some sort of bastardised CRM - even though we have a pretty capable CRM already.

Comment Re:Why are you here? (Score 1) 159

If they don't like you putting that out there due to branding issue then I'm sure they're going to love you for posting all about the problems with JIWA Financials on Slashdot of all places. What were are you thinking?

I'm here to see if my stance is reasonable or not. Validation, I guess - but also some opposing viewpoints to mine with more substance than what I was getting from our Sales team. They were not articulate or convincing enough for me to be enrolled with their views - so here I am.

I'm not overly concerned about people seeing our issues. I'm rather proud of the fact that we currently are transparent about it and anyone viewing it can see we are active and professional in our conduct.

You mentioned the company I work for - I have no reason to hide that, but chose not to mention it as I didn't want to seem like this was an advertising pitch. I'm not sure what your motivation was for bringing it up, but thanks for the exposure :)

What was I thinking? I was thinking I could engage a community of like minded professionals, with varying degrees of experience to offer their opinion so I could feel more comfortable about making a decision. I don't like making uninformed decisions.

Why are you here?

Comment Re:Not so public disclosure (Score 1) 159

OP Here,

That is certainly on the cards, and after seeing a lot of the comments here I will go down that path - that and having a sanitised list of changes with each public release of what was fixed or introduced and only reported before or in the last public release.

Common sense told me there was *some* merit to what the sales droids were saying, but I needed some outside opinion and I think I certainly have received that opinion now.

Also - sorry about the long summary - I have never submitted to slashdot before and assumed it would be truncated or edited suitably if published. Another day, more knowledge acquired - that's a win for me I guess :)


Submission + - Ask Slashdot: Software issue tracking transparency - good or bad?

Mike Sheen writes: Software issue tracking transparency — good or bad?

I'm the lead developer for an Australian ERP software outfit. For the last 10 years or so we've been using Bugzilla as our issue tracking system. I made this publicly available to the degree than anyone could search and view bugs. Our software is designed to be extensible and as such we have a number of 3rd party developers making customisations and integrating with our core product.

We've been pumping out builds and publishing them as "Development Stream (Experimental / Unstable" and "Release Stream (Stable)", and this is visible on our support site to all. We had been also providing a link next to each build with the text showing the number of bugs fixed and the number of enhancements introduced, and the URL would take them to the Bugzilla list of issues for that milestone which were of type bug or enhancement.

This had been appreciated by our support and developer community, as they can readily see what issues are addressed and what new features have been introduced. Prior to us exposing our Bugzilla database publicly we produced a sanitised list of changes — which was time consuming to produce and I decided was unneccessary given we could just expose the "truth" with simple links to the Bugzilla search related to that milestone.

The sales and marketing team didn't like this. Their argument is that competitors use this against us to paint us as producers of buggy software. I argue that transparency is good, and beneficial — and whilst our competitors (Dynamics NAV, MYOB Exonet, SAP Business One, et cetera) don't publish such information — but if we were to follow our competitors practices we simply follow them in the race to the bottom in terms of software quality and opaqueness.

In my opinion, transparency of software issues provides:
  • Identification of which release or build a certain issue is fixed
  • Recognition that we are actively developing the software
  • Incentive to improve quality controls as our "dirty laundry" is on display
  • Information critical to 3rd party developers
  • A projection of integrity and honesty

I've yielded to the sales and marketing demands such that we no longer display the links next to each build for fixes and enhancements, and now publish "Development Stream (Experimental / Unstable" as simply ""Development Stream", but I know what is coming next — a request to no longer make our Bugzilla database publicly accessible. I still have the Bugzilla database publicly exposed, but there is now only no longer the "click this link to see what we did in this build".

A compromise may be to make the Bugzilla database only visible to vetted resellers and developers — but I'm resistant to making a closed "exclusive" culture. I value transparency and recognise the benefits. The sales team are insistent that exposing such detail is a bad thing for sales.

I know by posting in a community like Slashdot that I'm going to get a lot of support for my views, but I'm also interested in what people think about the viewpoint that such transparency could be bad thing.


Comment What about the skin temp ? (Score 1) 201

I'm no aerospace engineer, but I imagine the temperature of the aircraft skin would get hot pretty quick at such speeds. What materials is this craft made of, and how do they combat the problems of heat caused by air rushing so quickly over the aircraft ? Making an engine work in short bursts is one thing, making an aircraft capable if withstanding that velocity through atmosphere is another.

Slashdot Top Deals

Happiness is a positive cash flow.